Sunday, November 01, 2009

Utility Programs, Part I - Printers

Stephen Morgan's FoxPro Projects - Utility Program Details


This area offers details of some major general-purpose programs used in some form by almost all the full application programs I wrote. Unless noted, all these programs were written in FoxPro 2.0, for DOS. Some early programs started out in dBASE III PLUS or FoxBase, but all were converted to FoxPro at some point.

Printer Menu

One of the first versions of the printer menu program was as a short list of available printers for the Technical Library program. The list included a high speed LAN printer. At that time, the Novell CAPTURE command was used to access the printer, but this caused memory problems if the command was used more than once or twice in a program session. Eventually, FoxPro added a command to access printers on a Novell network, and that command was substituted.

The printer menu eventually had four or more options, with the LAN printer being one of them. The printer codes were usually placed just before the report began and just after it ended, though some hand-coded reports had internally placed codes because of such things as expanded-print bold titles and different character spacing at different points in the reports. The printer codes were soon placed in variables instead of being stated directly, though extra steps were necessary in processing the LAN printer because of the requirement of connecting and disconnecting. Not all programs were given a printer menu, though the Engineering programs usually were. It became a problem to keep updating the code for all the programs, so I eventually wrote a separate program.

In the separate printer program, the printer names and printer codes were kept in tables instead of being hard coded. Three tables existed: one with the users' names and printer choices; and with the printer names and codes; and one with the actual menu options. The one with the menu options also tracked whether the printer was LAN or Local, and the server name was also recorded. Key numbers existed for the menu options and for the printer definitions.

Though the program worked well, it had a major deficiency in that it did not have the ability to edit anything. All editing had to be done directly from FoxPro. I had not wanted to get too deeply into writing a printer program because I was expecting FoxPro to offer a printer selection utility. However, the utility FoxPro offered was extremely slow in operation and required setting up predefined report definitions. This meant that I had to either set up a report definition for all necessary printers and continue offering the user my own menu, or rely on the user to set up the definitions (and to know what the definitions should be). For example, a user would have to know that a report required 17 characters per inch. Also, although a table of printers and codes was provided, altering anything required recompiling the utility. The utility could also be used only with FoxPro report forms, and not with hand-coded reports, which were sometimes absolutely required for Engineering printouts.

It became evident that FoxPro would not provide what I was looking for. Also, some programs on which I wished to implement the printer menu were going to be released to other locations, and it would not be right (or workable) to require the users at the other locations to set up the printer records directly from FoxPro. I then created the second major version of the separate printer menu program.

In the new version of the program, the menu options and printer definitions were set within the program. The users were not manually set within the program, as the program automatically detected new users and added user records as necessary. User names were placed in a variable in the DOS environment at the time of network login, and most of the programs accessed that variable for a user name, though Status Monitor had a partially separate system. All that was needed was a common variable name that the printer program could access, or at least a known range of possibilities. The programs did not in fact all have the same user variable name, so the printer program checked for all reasonable variations on the variable name before looking for a name in the DOS environment. (Some initial user variable name possibilities were User, MUser, UserName, and MUserName. This list was later expanded after variable type and scope prefixes were added, producing variations such as cUserName and gcUserName. Although I did not personally implement scope prefixes, I thought it best to check for them in order to handle possible future situations.)

What the printer program did was set public variables with the users' printer choice, and save key numbers recording the users' choice in a record. Normally, the printer program did not save a LAN printer choice, but could be configured to allow this.

When a report was to be printed, modules within the application program, not the printer program, accessed the variables, connected to the named file server if the choice was a LAN printer (or connected to the default server if a server was not explicitly named), and sent the appropriate printer codes (held in code variables such as cCPI10, cCPI17, cLPI6, and cLPI8) for that report. After printing, the printer codes to restore the normal printer state were sent, and if the printer was a LAN printer, a disconnect was sent by setting the printer to local.

This allowed both report forms and hand-coded reports with internal printer codes to be used.

My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Program List
Utility Programs, Part I - Printers
Utility Programs, Part II - Error handlers
Programs, Part I
Programs, Part II
Programs, Part III
Programs, Part IV

Labels: , ,


Post a Comment

<< Home

Newer Posts . . . . Older Posts