Integrating, Tagging, Printing, and Expanding

Transcription

1 Integrating, Tagging, Printing, and Expanding Peter Vogel Access Answers Smart Access In this month s Access Answers column, Peter Vogel looks at replacing perfectly good Access functions, having multiple utilities share a control s tag property, printing PDF files from Access reports, and the issues around creating an expanding/ contracting form. He also disappoints at least one reader. My Access 2.0 application used the TransferSpreadsheet command for many long and successful years. I even upgraded the command from a macro to a VBA command (using the DoCmd object). The TransferSpreadsheet command survived successive upgrades through Access 95/97/2000. We ve just moved the code to an Access Data Project and I can no longer use TransferSpreadsheet. Am I doomed? You re not doomed, though you ll have to abandon the TransferSpreadsheet command. But you re on the verge of taking advantage of one of the most powerful commands in Access 2002 (though this new command has been available since Access 97, at least). Don t panic, though; the change in your code is minimal. By the way, you can keep using TransferSpreadsheet but not the way that you re doing it now. As long as you stay away from Access Data Projects, you can use TransferSpreadsheet with tables or queries. Once you move to ADPs, queries disappear and are replaced with views, functions, and stored procedures. TransferSpreadsheet won t work with these objects. Instead, you get a mem (misleading error message) that Access can t find the specified view, function, or stored procedure. It s not that Access can t find them; the problem is that TransferSpreadsheet won t work with those objects. I ve seen a number of different solutions for this problem, all of them too complicated. One solution is to use SQL Server s Data Transformation Services (DTS), while another solution exports the data to a table in another database and then exports the data from there. There s a much simpler method in Access 2002: OutputTo. This powerful and flexible method gives you all the capabilities of the TransferText and TransferSpreadsheet methods of the DoCmd object, and much more. The format of the OutputTo method looks like this: DoCmd.OutputTo objecttype, objectname, outputformat, _ outputfile, autostart, templatefile, encoding To output your ADP view, you ll need to set the objecttype parameter to acformatserverview. The real power in this command is in the outputformat parameter. There s no IntelliSense support for this parameter, so you ll have to look it up in the Access Help system (or guess at the options from the dropdown list in the Access Macro Editor, which does list all the options). There are eight options for this parameter: acformathtml: HTML acformattext: Text files acformatasp: Active Server Pages acformatxls: Microsoft Excel acformatiis: Microsoft IIS acformatsnp: Access Report Snapshots acformatrtf: Rich Text Format acformatdap: Data Access Page The dropdown list in the Access Macro Editor lists three options for Excel Excel, Excel 5-7, and Excel but, in Access 2002, the output seems to be identical for all three versions. The list in the Macro Editor also varies depending on the type of object you select (the Snapshot format only appears if you re outputting a report, for instance), which provides some guidance on which options can be used together. I also found that the method was more reliable from code than from a macro. For instance, I wasn t able to create an RTF file when I used OutputTo from a macro, but I had no problem with doing that from code. The acformatxls option is obvious: It produces an Excel spreadsheet. Two of the other options are interesting but would only be used during design time rather than being used at runtime: The acformatasp option produces an ASP page with ADO code that reads the table and displays the data in a table. The code isn t complete though, as it s missing the connection string to connect to the database. The acformatiis produces the skeletons of the IDC and HTX files that you d need to integrate the output with Microsoft s search engine, Index Server. Presumably, you d use these two versions of the 14 Smart Access December 2002

2 OutputTo method to get a quick start on creating the ASP, IDC, and HTX files and then complete them yourself. The result of outputting an Excel spreadsheet can be seen in Figure 1. If you feel that you want to dress up the display, you have two choices. First, you can specify an Excel template file in the sixth parameter of the OutputTo method. Second, you can use Automation to take control of Excel from Access and modify the spreadsheet through your code. A combination of the two methods would be to write an Excel macro and place it in the template file (manipulating Excel from within Excel is faster than manipulating Excel from an external application). I ve got three neat utilities that I want to use in the same form. All of them add some special functionality to the controls on my form but all of them use the control s Tag property to store information that the utilities depend upon. How can I get around having the Tag property used for three different purposes? There are a couple of ways to handle this but they ll all involve rewriting the code that comes with the three utilities that you want to use. Basically, you ll want to enhance these utilities so that they ll play well with others and stop overwriting each other s information in the Tag property. In the Access Developers Handbook, the bible of Access development, the authors recommend using a format for the Tag property that will let you store multiple values in the tag. They recommend using name-value pairs with semicolons separating each pair: utility1=value;utility2=value;utility3=value; The authors have even provided a class module that will read and update the string. However, it s the new millennium and you re probably obliged to use XML to store data. Inventing a set of tags to hold Tag information, I came up with this format: <tagvalues><utility1>value</utility1> <utiltity2>value</utiltity2> <utiltity3>value</utiltity3></tagvalues> As you can see, each value is identified by an open and close tag that takes its name from the utility that uses the data within the tag. The root element that encloses all the tags is called tagvalues. You can have as many utility tags as you want I used three because that matches your scenario. You ll also want to give the tags more meaningful names. To read the Tag values, you ll need to add the Microsoft XML tools to your project s References list. Reading the tags from a control and finding the value for a particular utility s value looks like this (I used Version 4, the latest version of Microsoft s XML tools, but the code is identical for whatever version is installed on your PC): Dim doc As MSXML2.DOMDocument Dim nd As MSXML2.IXMLDOMNode Dim strvalue As String Set doc = New MSXML2.DOMDocument doc.loadxml Me.TextBox1.Tag Set nd = doc.selectsinglenode("//utility1") If nd Is Nothing Then strvalue = "" strvalue = doc.text The code to handle updating the tag is slightly more complicated. The code first searches for the utility s element in the control s Tag property. If the element isn t found, the code creates the element and adds it to the document. With the element now guaranteed to be in place, the element is then updated: Dim doc As MSXML2.DOMDocument Dim nd As MSXML2.IXMLDOMNode Dim strvalue As String Set doc = New MSXML2.DOMDocument doc.loadxml Me.TextBox1.Tag Set nd = doc.selectsinglenode("//utility1") If nd Is Nothing Then nd = doc.createelement("utility1") doc.documentelement.appendchild nd nd.text = "new value" This solution is probably overkill for your needs. In fact, given Access s notorious problems with handling its References list, building a solution that depends on adding a new item to the References list probably makes your code less reliable. However, this solution does give you all the benefits of using the XML parser to manage your text strings. In this month s Download file (available at ), I ve included a function that returns the value requested for a utility name and a subroutine that updates the value for any tag. If the tag hasn t been initialized to a valid XML value, the root element for my document (<tagvalues> </tagvalues>) replaces whatever is in the Tag property. To incorporate these routines into your application, add the code module to your program and call the routines: strreturnvalue = demotagreader("utility1", Me.TextBox1) demotagwriter "utility1", Me.TextBox1, "new value" Figure 1. Default format for displaying an Access table in Excel. Smart Access December

3 I want to be able to create PDF files from my Access programs. Is this even possible? It certainly is possible, but you ll need to buy a utility that will actually generate your PDF files. There are a number of these utilities available. I happen to use Win2PDF from Dane Prairie ( It hasn t let me down yet and met one of my primary criteria for a utility that I won t use very often: It was cheap ($35.00US). To use Win2PDF from an application, you just print as you would normally but select Wind2PDF from the printer selection dialog (see Figure 2). To replicate this process from code, you ll need Access 2000 or 2002 so that you can use the Access Printer object. First you must declare a variable to point to a collection of printers available to your application and a variable to point at a single printer. You can then retrieve the name of the Access Application object s current printer so that you can switch Access back to the default printer after you ve printed your PDF file: Dim prts As Printers Dim prtcurrent As Printer Dim strcurrentprinter As String Set prts = Application.Printers Set prtcurrent = Application.Printer You re ready now to set the printer to the PDF device. First you must find the PDF printer in the list of printers available to the Application object, and then set the Application s Printer property to that printer (you ll need to know the name of the PDF printer). With those two steps done, you can print your object: Set Application.Printer = prts("win2pdf") DoCmd.PrintOut acpages Finally, you should set the Application back to the default printer: Set Application.Printer = prtcurrent You don t have to do this at the application level. You can also manipulate the printer for the form or report that your code is executing inside of: Set prts = Application.Printers Figure 2. Selecting the Win2PDF printer. Set prtcurrent = Me.Printer Set Me.Printer = prts("win2pdf") DoCmd.PrintOut acpages Set Me.Printer = prtcurrent This isn t a perfect solution, unfortunately. When you use Win2PDF, it pops up a dialog box that asks you to enter the name of the file that you want the PDF file put in. For a completely silent operation, you ll need a PDF printer that you can automate from Windows. Also, while I like Win2PDF, it doesn t run on Windows 95, 98, or Me. I ve got a form with several fields/buttons that I only want to display some of the time. Is there some way to have an Advanced button on the form so that it reveals those options only when my users need them? There are a number of solutions to this problem, but first let me congratulate you for thinking about your users rather than just putting all the form s functionality up on the screen. Provided that you can do a good job of discriminating between what your users need 90 percent of the time and what they need only occasionally, you ll have a gone a long way toward having your form do a better job of supporting your users jobs. I ll begin by clarifying the problem: What you want to do is switch the form between an advanced state and the basic state. Unless you want to leave the form in the advanced state after the user displays it, you ll also need to write the code to return to the basic state. One solution is to simply make all the controls that you don t want your users to use invisible by setting their Visible property to False. The problem here, of course, is that this strategy can leave a great empty space on your form that will look odd when only the basic controls are displayed. There s also additional testing required should you add another control to the advanced functions. You ll have to remember to update your code to make the new control appear and disappear at the right time. Because of that, you only want to use this option if the advanced function consists of only one or two controls (say, a button and a text box). If that s that the case, by the way, you should probably just leave them on the screen all the time. Another solution is to avoid disappearing and reappearing controls altogether. Instead, you could use the Access tab control and label one tab as Advanced. This would be a better choice than hiding and revealing the controls if the user interacts with the advanced controls more often than about 25 percent of the time (on the assumption that switching to a different tab is easier to deal with conceptually than having a form redraw itself). However, you should only adopt this strategy if the user can work with the controls on the advanced tab independently of the controls on the basic tab. If your users have to switch back and forth between the two tabs, you re just going to drive them nuts. So, I ll assume that you have several controls to add 16 Smart Access December 2002

4 to support the advanced functionality, that the typical user will interact with them less than 25 percent of the time, and that the advanced and basic controls need to be on the screen at the same time. The first thing to do is add the button to your form that will expose the new controls. I m following the convention that I ve seen in some Windows dialogs where the control initially has Advanced>> as its caption. So, I ll set the button s caption property to Advanced>> at design time. In this convention, clicking on this button should display the new controls and change the caption of the button to <<Basic. The code to implement the changes between the form s two states would look like this: Static bolexpanded As Boolean I ve set up a Static variable (one that retains its value between calls to the routine) to keep track of the form s state. This is dangerous presumably the variable could get out of synchronization with the actual state of the form. Since I m going to expand and contract the size of the form, I could have used the form s size to determine what state I was in. I stayed away from that design because I was concerned that if I made a small change in the size of the form during design time, then I would invalidate the If statement that checks the form s state. I m now ready to expand and contract the form. The simplest way to do this is to manipulate the form s InsideHeight property. In this case, I ve arbitrarily decided to just double the size of the form: Figure 3. The expanding and contracting form in design view. Static bolexpanded As Boolean Adding some actual controls to the form gives it the appearance in Figure 3 in design view. The expanded and contracted versions can be seen in Figure 4 and Figure 5. As you can see, Access doesn t display a scrollbar when a form isn t fully displayed. However, the user can still get to the controls in the lower part of the form by tabbing to them. To prevent that from happening, I ll need to disable the controls or make them invisible. This takes me back to the potential problem of adding a control to the advanced part of the form but failing to hide/reveal it appropriately. It would be nice if Access forms had a Panel or Frame control that would let me treat a set of controls as a group but it doesn t. However, Access does have subforms, so I ll copy all of the advanced controls to a second form and drag that form back onto my dialog. I ll set the subform s SpecialEffect property to flat and the BorderStyle property to transparent so that the subform will blend in with the rest of the form. I ve called the subform control sbadvanced, so the next version of my code looks like this: Me.sbAdvanced.Visible = True Me.sbAdvanced.Visible = False There are two problems with this code. The first is that the user can t tab from the advanced controls out of the subform back to the controls in the basic form. The second problem is that I just doubled and halved the InsideHeight of the form s window in my code. As a result, every time that I save the form I have to make sure that I ve set the form s window to some appropriate size. Figure 5. The advanced form. Figure 4. The basic form. Smart Access December

5 You d be better advised to use some hard-coded value. One last change and I m done. I ve set the subform s Visible property to False at design time so that it won t display when the form loads. I can use that value to keep track of my form s state and eliminate my bolexpanded variable: If Me.sbAdvanced.Visible = False Then Me.sbAdvanced.Visible = True Me.sbAdvanced.Visible = False I ve used the CommandBars objects and the Office Assistant from my code since they first were available from Access. Can I do the same with the Access 2002 task pane? No. Sorry. AA0212.ZIP at Peter Vogel (MBA, MCSD) is the editor of the Smart Access newsletter and a principal in PH&V Information Services. He s also the author of The Visual Basic Object and Component Handbook (Prentice Hall, currently being revised for.net). His articles can be found in the MSDN libraries, and are included in Visual Studio.NET.. 18 Smart Access December 2002