[ Team LiB ] |
Recipe 17.6 Print an Access Report from .NET Windows Form Application17.6.1 ProblemThe Solution in Recipe 12.2 illustrates how to print an Access report from Excel. Is it also possible to print an Access report from a .NET Windows Form application? 17.6.2 SolutionPrinting an Access report from another application requires you to automate the Access application. The Solution in Recipe 12.2 shows how to do this from Excel, which like Access is a COM-based program. The process for automating Access from a .NET application is very similar. The only difference is that a .NET application cannot directly call a COM program (or component). To call a COM-based program from .NET, you must obtain a runtime callable wrapper that calls the COM-based program on your behalf. (This process is the reverse of calling a .NET component from a COM-based program as discussed in the Solution in Recipe 17.1.) Runtime callable wrappers are also known as interop assemblies. Using the Office 2003 setup program, you can install the interop assemblies for various Office applications, including Access. Depending on the path you take through the Office 2003 setup program, you may or may not have installed the interop assemblies. Fortunately, you can modify an existing Office 2003 installation to add one or more interop assemblies. The interop assemblies are listed under each product in the Office 2003 setup program under the heading ". NET Programmability Support." If you have installed the interop assemblies, when you set a reference to Access 2003 or another Office application from Visual Studio .NET, your code will automatically use the installed interop assembly. Follow these steps to create a Windows Form application named AccessReporter that automates Access 2003, opens the 17-06.MDB database, and runs the rptArtistAlbum report:
Figure 17-10. The Visual Studio .NET Add Reference dialog box
Figure 17-11. The AccessReporter Windows Form application is shown in front of the Access report it has previewed
17.6.3 DiscussionHere's the basic process followed by the AccessReporter application to run the Access report:
17.6.3.1 Shutting down AccessThe PrintArtistReport form includes a checkbox control to determine if the report is to be previewed or printed. If the report is to be previewed, then it is necessary to make Access visible to allow the user to view the report. In this case, it will be up to the user to close down Access: accApp.DoCmd.OpenReport(strRpt, Access.AcView.acViewPreview, , _ strWhere) accApp.Visible = True If the report is to be sent to a printer, the code takes a different path. There's no need to make Access visible. In fact, Access is shut down after the printing is complete: accApp.DoCmd.OpenReport(strRpt, Access.AcView.acViewNormal, , _ strWhere) accApp.DoCmd.Quit( ) This code alone, however, will not remove Access from memory. That feat is accomplished with this additional line of code: System.Runtime.InteropServices.Marshal.ReleaseComObject(accApp) If you do not call the ReleaseComObject method, Access will not be removed from Memory until the AccessReporter application is closed. 17.6.3.2 Communicating parameters to AccessWhen automating Access 2003, you have no way to supply parameters to a parameter query, thus you must devise some other technique to pass parameters from your .NET application to Access. In many situations, you can construct a WHERE clause and pass it to the report using the fourth parameter of the call to the OpenReport method. This is the technique that was used in this solution. There may be some situations where constructing a WHERE clause is too cumbersome. For example, if you used a listbox control that allowed for multiple rows to be selected, the WHERE clause could be inordinately long. In this case, another option would be to use a "parameters" table to which you would add the selected rows. You could then create a query that joined to this parameters table and base the report on this query. Before running the report your code would need to iterate through the rows in the listbox and, using ADO.NET, insert a row into the "parameters" table for each row of the selected listbox rows. 17.6.3.3 Interop assembliesThere are two types of interop assemblies: primary interop assemblies and alternate interop assemblies. Anyone can generate an alternate interop assembly (AIA) for any component by setting a reference to a COM component from Visual Studio .NET (which generates the AIA by calling the tlbimp utility that ships with the .NET Framework). A primary interop assembly (PIA) is the official interop assembly that has been produced and signed by the component's author. While the tlbimp utility usually does a good job in generating the AIA for a component, there may be situations where the types are not mapped properly. PIAs, on the other hand, are usually hand-optimized beyond the code automatically generated by tlbimp. Whenever it is available it's preferable to use the PIA rather than an AIA.
As mentioned in the solution, Office 2003 ships with PIAs for each of its applications. You can download the PIAs for Access 2002 and the other Office XP applications from the following URL: http://msdn.microsoft.com/library/default.asp?url=/downloads/list/office.asp Microsoft has no plans to supply PIAs for Office 2000 or Office 97, so you will have to generate and use AIAs for these applications. 17.6.4 See AlsoSee A Primer to the Office XP Primary Interop Assemblies (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnofftalk/html/office10032002.asp). |
[ Team LiB ] |