Figure 1. Housekeeping tab in the application, used to set up the printer selection for each PC.
by Ray Lyons
The Original Problem:
I have a mortgage processing application with a dozen or so form letters, labels and regular reports. These print jobs are always printed on a “current record only” basis for the client the user is working with at the moment. There are about 15 users on an NT 4 network with 5 different network printers (2 of which are color laser printers) in two buildings about 100 hundred feet apart. Some letters and other print jobs are printed one day, and then a few days later others are printed and so on until the loan process is completed. Each time a user works with a client they need to know what has already been printed (and when) and they need to be able to select a combination of as many 3 or 4 print jobs at a time (e.g., a letter, an appraisal request, etc.). A print menu with a record of the date a job was printed was easy enough.
But there was more. The owner of the business does not want his people to have to think much about what they are doing, doesn't want them to have to spend even 10 seconds to do something if it can be avoided, and does not want to have to spend a lot of time and money training people. He said something to the effect, can't you just have them make a few print job selections, press a button and then go back to work on something else or get right up and head toward the printer?
My V4 Solution:
My version 4 solution to this was to save printer parameters in layout (e.g., report properties, printer, specify printer, saved properties). This more or less worked. However, there were problems. First, it was not convenient for all users to use the printer I set up and saved in the layout (and I already had more layouts to maintain than I wanted). Second, and more troubling, was the mix of workstation operating systems, namely both w2k and win98. The printer drivers are quite different between the two, such that if I saved my printer properties using a wk2 driver, that might not work for the win98 user. Third, and by far the biggest problem, was this: For reasons I do not understand, almost every time I made a small change to a layout and put the change into production at the client site, the saved printer properties in all the layouts (not just the one I had changed) were lost and had to be reset on the client's system. This was true even though my development machine had the very same printer drivers. When there are frequent changes and you have 15 layouts effected, this soon becomes intolerable. It got so bad that I was seriously considering moving the whole thing into Access where I knew I could have better control of the printers. I am not sure it had anything to do with it, but when I informed Selwyn and his crew of my problems, almost like magic a few months later v5 comes out with a printer_override() function. And you ask why we should love Alpha Software!
My V5 Solution:
Anyway, along comes v5 with its printer_override() function. With some crucial help from the fantastic programmers at Alpha Software, I was able to solve the problems in the ways outlined in this article and sample database. I decided that each workstation would have a printer setup for the print jobs in question, while other print jobs could just use the usual printer selection methods.
Briefly, it goes something like this: For everyone using the application, standard types of jobs or “usages” (Letterhead, Labels, Legal, etc.) are set up in a table named Ptr_usages. Then on each workstation one runs a script (Gen_Codefor_PtrRec) that allows the administrator (or user) to select a printer and its parameters that are to be used for that type of job (usage). This is a fairly complicated script which both warrants study and which could probably be cleaned up a bit. In any case, what it does is to actually generate and save a script named (Gen_Ptr_rec) with the selected printer and its option parameters in the generated script. This generated script (Gen_Ptr_rec) is run immediately after it is created (one button runs both scripts). What it does is empty and then write a record to a temporary table (Ptr_temp) containing the usage (e.g. Letterhead), the printer to be used for this usage on this workstation and its option parameters (e.g., Tray 3, etc.). Finally it runs a saved operation named Append_Temp_PTR, which appends this record to the Ptr_overrides table for later use by the Ptr_override script. When a print button plays the Ptr_override script, it retrieves data from the Ptr_override table.
Figure
1. Housekeeping tab in the application, used to set up the printer
selection for each PC.
Figure
2. The housekeeping form for the printers establishes different types
of documents.
Figure 3. Here we have selected a document type (Letterhead) for this PC, chosen a printer and set the default number of copies for this document type from this workstation.
A print button script on a form specifies, through global variables to be used in the Ptr_override script, how many copies to print and the usage type (label, letterhead, etc.). The button script then plays the Ptr_override script. Using the computer name and the usage type, it goes to the Ptr_overrides table and finds the printer name and option parameters for this type of usage (e.g., Letterhead) on this workstation. Using a global variable, all this information is passed back to the print button script for use in a somewhat modified, genie generated Printer_override() code segment. When finished the selected printer is set back to defaults. If another job has also been selected in this same run, the process is gone through again and again until all selected jobs have been printed.
My original intention was to write an article going into much more detail of what is going on in the scripts. However, that intention has existed for over a year, and it is now clear that I am never going to have time to do it. Thus, in spite of some embarrassing bumps and warts, I decided to produce this sample database and hope that most readers can examine the code and figure out what is going on in more detail than is outlined here.
A great deal of time has gone into creating this way of solving the problems outlined above. If you improve upon it in some significant way, I ask that you please send me the improvements. If you use any of the key components in your own commercial application, you might consider sending me a donation ($10?) to help cover the many, many uncompensated hours I have spent on this project (RayLyons@Mailcan.com).
My apologies if I have mis-described anything in the above. It has been a long time since I developed this system and I may not be remembering everything with 100% accuracy.
Raymond Lyons
Raymond Data & Consulting, Inc.
1/25/2004
Don't forget, we need your feedback to make this site better!
Download the sample database and scripts.