Programs, Part I
Stephen Morgan's FoxPro Projects - Details
Introduction
This provides a brief description of some of my past FoxPro projects, with extra information given when unusual or special features are present. 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.
Status Monitor
This project was a very large one, and was also one of the early ones. Initial programming was in dBASE III, but was soon moved to FoxBase. Movement to FoxPro (v1) took place either before initial use of the program or soon after. An oddity which required some reprogramming was that FoxPro did not normally have a space before and after the popup menu options, while FoxBase did. Since the program displays were written to incorporate the extra spaces, the code had to be modified.
Although this was a small thing, it was disturbing to see incompatibilities displayed so quickly, and it made me wonder about what else was ahead, and whether future versions might have more of this. Also, although FoxPro had added new popup and the menu commands, I decided to stay with FoxBase versions for now, as I did not see a great need for the new ones. The action of the new menu bar seemed counterintuitive, because users were used to seeing menus constantly displayed, instead of the menu disappearing into the menu bar. (I had trouble with users who did not understand menu bars, even when the popups were always displayed. They did not understand how to use the arrow keys to get from one popup to another.)
Other than this, there turned out not to be much trouble in the language changeover. I eventually found a FoxPro bug in the array-based popups I was using, where the chosen bar decreased by one each time the user selected an option. That is, the highlighted bar when the menu was reactivated was the bar above the previous selection, as long as a previous selection was available. I felt this was confusing, so I wrote code to correct it. I also later found that some keys acted differently. For instance, the End key moved the selection to the last bar for DEFINE POPUP structures, but (I believe) closed the menu and activated the current selection for array-based popups. These were good reasons to change over to the new POPUP command. I was concerned about memory usage, as the new commands created structures that remained in memory unless specifically removed, and lack of memory was a problem with some computers. I did eventually change most programs to the new commands, taking care to remove menus from memory when no longer needed, but some array-based menus remained in places.
The Status Monitor program showed Equipment status in hierarchical color-coded lists which could be set to continually scroll or manually paged up and down. The equipment lists had two major divisions based on both location and official equipment groupings. Separate or combined viewing of lists of equipment from these two main locations was possible.
Two different passwords existed, one for users who might have to acknowledge viewing the status changes or who might edit the status (acknowledgements and all edits were recorded) and one for users who might edit the equipment itself and other users. Users were not required to know a password, but such users were limited to viewing or printing. Additionally, all users were entered in a table, along with their rights. The rights usually limited them to viewing, but some users had lists of equipment for status editing, and other users had broader equipment status groups for status editing.
Since the LAN link between the two main locations was subject to frequent outages at the time the program was conceived, the program was written so that copies of the data were kept at both locations. Under normal conditions, both locations were updated with each edit, but if a server was unavailable, the programs could run independently and update only the data at the programs' physical location. The data was synchronized after the link was up by either reediting the record in question or by choosing a menu option to copy one file over another.
ECP Summary
ECP's are Engineering Change Proposals. This program tracked ECP Summaries, and was one the extremely early programs. A separate 'ECP History' list was also kept by this program. The History was a brief collection of information from the summary, and included a shortened title, to allow easier printing and displaying.
Within the program, the ECP to be edited could be chosen by either entering the number directly or by viewing the History list and then entering the number.
Normally, an ECP Summary was just printed once, so the program tracked that, but still left an override available so that the Summary could be reprinted if necessary.
This, and almost all the Engineering programs, had a rights system that allowed, as a minimum, the ability to set a user to either have editing rights or display-only rights. Initially, this was accomplished by maintaining a separate display-only program, with users separated by Novell menus taking them to their respective programs, but I later combined the versions and used a simple user rights setup within the programs themselves.
ECP Pages
The ECP Pages program was a long time getting finished, because of the extreme complexity involved and because the government kept updating the pages. The initial plans for the program were extremely difficult to accomplish in dBASE III, and contained such things as help for each field. The help would be displayed if the user wanted help when editing that field.
This is relatively easy in FoxPro, but could only be accomplished in dBASE III if each field had its own READ command. In order to present a normal display, the screen had to first be painted, including all the GETs. As the user traveled through the GETs, each one was READ and then the method of exit was checked to see what the user wanted. If the user wanted help, the help was displayed and the user was then returned to the screen. (Remember, no separate windows were available, so the screen had to be repainted each time.) If the user did not want help, and if the user was not trying to exit the screen, the direction of exit from the field was checked, to determine what field the user should be placed on next.
In practice, in order to keep the code to a manageable size, this resulted in assigning the fields to pseudo array variables (dBASE did not have arrays), with names such as varname11, varname12, etc., and lots of macro expansion. Before the program was completed, though, we moved to FoxBase and then FoxPro. This made programming a lot easier, but it required that everything be rewritten. By that time, the code was so dense that I had to proceed carefully, as it was no longer clear in many cases exactly what the code was doing, even though I had written it and knew the general outline of what was happening. In the end, though, I fully converted it all.
The ECP pages were numbers 1 through 6, SCN's, MCN's (actually modified SCN's, and thus not really a separate page, but they were used as such), and attachments. In practice, word processor documents and CAD drawings and such were usually used instead of the program attachment section, but it was included for completeness.
The pages were based on pre-existing government forms. For example, page 1 was DD Form 1692 and page 2 was DD Form 1692-1.
Some of the pages were extremely lengthy, sometimes over 100 fields, and sometimes required special handling, such as spreadsheet-style calculations and editing on one page causing updates of other pages.
A page 7 was later added by the government. Page 7 was similar to page 6, and both required landscape print settings.
The ECP Pages program was the first of the programs to offer the choice of printing high quality forms if an HP LaserJet printer was chosen from the Printer menu. The forms were hand-coded and the graphics and test were micro-positioned. A great deal of trial and error was involved, but the process became faster as time went on.
My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
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
Introduction
This provides a brief description of some of my past FoxPro projects, with extra information given when unusual or special features are present. 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.
Status Monitor
This project was a very large one, and was also one of the early ones. Initial programming was in dBASE III, but was soon moved to FoxBase. Movement to FoxPro (v1) took place either before initial use of the program or soon after. An oddity which required some reprogramming was that FoxPro did not normally have a space before and after the popup menu options, while FoxBase did. Since the program displays were written to incorporate the extra spaces, the code had to be modified.
Although this was a small thing, it was disturbing to see incompatibilities displayed so quickly, and it made me wonder about what else was ahead, and whether future versions might have more of this. Also, although FoxPro had added new popup and the menu commands, I decided to stay with FoxBase versions for now, as I did not see a great need for the new ones. The action of the new menu bar seemed counterintuitive, because users were used to seeing menus constantly displayed, instead of the menu disappearing into the menu bar. (I had trouble with users who did not understand menu bars, even when the popups were always displayed. They did not understand how to use the arrow keys to get from one popup to another.)
Other than this, there turned out not to be much trouble in the language changeover. I eventually found a FoxPro bug in the array-based popups I was using, where the chosen bar decreased by one each time the user selected an option. That is, the highlighted bar when the menu was reactivated was the bar above the previous selection, as long as a previous selection was available. I felt this was confusing, so I wrote code to correct it. I also later found that some keys acted differently. For instance, the End key moved the selection to the last bar for DEFINE POPUP structures, but (I believe) closed the menu and activated the current selection for array-based popups. These were good reasons to change over to the new POPUP command. I was concerned about memory usage, as the new commands created structures that remained in memory unless specifically removed, and lack of memory was a problem with some computers. I did eventually change most programs to the new commands, taking care to remove menus from memory when no longer needed, but some array-based menus remained in places.
The Status Monitor program showed Equipment status in hierarchical color-coded lists which could be set to continually scroll or manually paged up and down. The equipment lists had two major divisions based on both location and official equipment groupings. Separate or combined viewing of lists of equipment from these two main locations was possible.
Two different passwords existed, one for users who might have to acknowledge viewing the status changes or who might edit the status (acknowledgements and all edits were recorded) and one for users who might edit the equipment itself and other users. Users were not required to know a password, but such users were limited to viewing or printing. Additionally, all users were entered in a table, along with their rights. The rights usually limited them to viewing, but some users had lists of equipment for status editing, and other users had broader equipment status groups for status editing.
Since the LAN link between the two main locations was subject to frequent outages at the time the program was conceived, the program was written so that copies of the data were kept at both locations. Under normal conditions, both locations were updated with each edit, but if a server was unavailable, the programs could run independently and update only the data at the programs' physical location. The data was synchronized after the link was up by either reediting the record in question or by choosing a menu option to copy one file over another.
ECP Summary
ECP's are Engineering Change Proposals. This program tracked ECP Summaries, and was one the extremely early programs. A separate 'ECP History' list was also kept by this program. The History was a brief collection of information from the summary, and included a shortened title, to allow easier printing and displaying.
Within the program, the ECP to be edited could be chosen by either entering the number directly or by viewing the History list and then entering the number.
Normally, an ECP Summary was just printed once, so the program tracked that, but still left an override available so that the Summary could be reprinted if necessary.
This, and almost all the Engineering programs, had a rights system that allowed, as a minimum, the ability to set a user to either have editing rights or display-only rights. Initially, this was accomplished by maintaining a separate display-only program, with users separated by Novell menus taking them to their respective programs, but I later combined the versions and used a simple user rights setup within the programs themselves.
ECP Pages
The ECP Pages program was a long time getting finished, because of the extreme complexity involved and because the government kept updating the pages. The initial plans for the program were extremely difficult to accomplish in dBASE III, and contained such things as help for each field. The help would be displayed if the user wanted help when editing that field.
This is relatively easy in FoxPro, but could only be accomplished in dBASE III if each field had its own READ command. In order to present a normal display, the screen had to first be painted, including all the GETs. As the user traveled through the GETs, each one was READ and then the method of exit was checked to see what the user wanted. If the user wanted help, the help was displayed and the user was then returned to the screen. (Remember, no separate windows were available, so the screen had to be repainted each time.) If the user did not want help, and if the user was not trying to exit the screen, the direction of exit from the field was checked, to determine what field the user should be placed on next.
In practice, in order to keep the code to a manageable size, this resulted in assigning the fields to pseudo array variables (dBASE did not have arrays), with names such as varname11, varname12, etc., and lots of macro expansion. Before the program was completed, though, we moved to FoxBase and then FoxPro. This made programming a lot easier, but it required that everything be rewritten. By that time, the code was so dense that I had to proceed carefully, as it was no longer clear in many cases exactly what the code was doing, even though I had written it and knew the general outline of what was happening. In the end, though, I fully converted it all.
The ECP pages were numbers 1 through 6, SCN's, MCN's (actually modified SCN's, and thus not really a separate page, but they were used as such), and attachments. In practice, word processor documents and CAD drawings and such were usually used instead of the program attachment section, but it was included for completeness.
The pages were based on pre-existing government forms. For example, page 1 was DD Form 1692 and page 2 was DD Form 1692-1.
Some of the pages were extremely lengthy, sometimes over 100 fields, and sometimes required special handling, such as spreadsheet-style calculations and editing on one page causing updates of other pages.
A page 7 was later added by the government. Page 7 was similar to page 6, and both required landscape print settings.
The ECP Pages program was the first of the programs to offer the choice of printing high quality forms if an HP LaserJet printer was chosen from the Printer menu. The forms were hand-coded and the graphics and test were micro-positioned. A great deal of trial and error was involved, but the process became faster as time went on.
My Time at Geocities
My Geocities Homepage
My Geocities Guestbook
Resume
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
posted by Stephen at 11/01/2009 01:04:00 AM
0 Comments:
Post a Comment
<< Home