Programs, Part II
Configuration Status Accounting Report
The Configuration Status Accounting Report program, another early program, was based on a report that had been generated in a word processor. The report actually consisted of two reports, one following directly after the other. That is, the second one began on the same page where the first one ended. The length of the reports varied, depending on the number of items in the reports, so the second report did not start on a fixed position, but needed enough room on the page for at least the header and a reasonable amount of data. The report was in a table format and every item, including the titles and each individual field, was enclosed by lines, forming a grid. The report was hand-coded.
The only printer code related oddity was the expansion of the title into double-wide, bold, separated letters, to match the word processor report. While it was possible to send the printer such codes, and I did set the report up to do it, it was difficult to make such a thing truly portable without being able to test the action of other printers. I did later put in a variation for HP LaserJets, though.
DCN
The Document Completion Notification program was an Engineering program, similar to some of the others, but using its own form. It was one of the later ones, and I think also set up to print high quality HP LaserJet reports, something that required a lot of testing, since I had to hand code all of it. And, like the other programs, it could also use a dot matrix printer.
This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.
ICN
The Installation Completion Notification program was an Engineering program, similar to the Document Completion Notification program if I remember correctly, but using its own form. It was one of the later ones, and I think also set up to print high quality HP LaserJet reports, something that required a lot of testing, since I had to hand code all of it. And, like the other programs, it could also use a dot matrix printer.
This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.
TEC
The Temporary Equipment Change program was based on a pre-existing paper form. The form was simple enough that a separate HP LaserJet version was not needed, but the hand-coded report still contained some specific areas where the printout was altered if an HP LaserJet was used.
Early versions of the program printed a Ford logo on the report, as I worked for Ford Aerospace at the time. I wrote the logo in Turbo C, because dBASE III, used at the time, did not permit direct input of the necessary printer codes. The codes were for a dot-matrix printer that the Engineering department used back then.
The form featured a large central area, where the temporary equipment changes were listed and described. In order to allow easy entry on the screen, with a format approaching that of the printed form, the area was divided into four parts: upper left, upper right, lower left, and lower right. The fields were laid out in a table format, and validation clauses determined the next field to access, based on the keys that were used to exit the current field. If the edge of the display was reached, the screen automatically changed to display the particular section that the user was heading for, with some overlap of the displayed data, so that the user could see a fragment of the other screen for reference.
A complication of the display was that some fields were split. In such cases, an area of the field from the next or previous screen was displayed, but was not available for data entry on the current screen, because the user needed to see part of what was in the section of the field on the other screen, and because if the area was currently available for editing the cursor would be placed on it and not where the user had been typing. Choosing a specific field to be activated when the READ began was not enough, because the field was only partially shown, even with the read-only part included. If the user had the entire displayed area for editing, the hidden part on the other screen would not be part of the edit and the user might overlook it or not realize that some other data existed there, particularly if the hidden section was on the right. The field was split only at the display, where it was divided into separate variables, and not in the actual field in the DBF table.
Engineering Taskings
The Engineering Taskings program began as a way to organize Taskings written in FormTool. The FormTool Taskings were based on a pre-existing paper form. The Taskings program imported the ASCII file portion of the FormTool record, which FormTool saved as an individual file (the other portion, saved separately by FormTool in a file with data from other forms, consisted of such things as underlining and other formatting). The file was placed in a long DBF field in a series of records. Each record had another field recording the Tasking number, which was extracted from the file name. The list of Taskings could now be easily displayed, and the tasking itself could also be viewed and printed from within the program. because of the large size of the form, the viewing was divided into several different screens, which could be reached with the arrow keys.
A different program was written by someone else, where the Tasking could be created and edited within the program. Unlike the previous program, where the report was hand-coded, the form was printed from a FoxPro report form. Since FormTool was no longer used to make the report, this meant that the large underlined section at the bottom, for hand-written notes, became instead a large blank area, but the Engineering department accepted this. The Engineering department had various complaints about the new program, and although I intermediated with the programmer, he was unwilling to make any more changes. The program was eventually given to me, and I rewrote it. (Still no underlines in the printouts, though. If they accepted the printouts without the underlines, why bother implementing them now.)
The old Taskings-converted-from-FormTool program remained in use, because it held the older Taskings that had not yet been entered into the new Taskings program.
Engineering Drawings
The Engineering Drawings program was a very early program, initially written in dBASE III, and later rewritten for FoxPro. It recorded Engineering department drawings. It basically recorded the drawing number and title, and various other useful related data.
Engineering Release Record Program
The Engineering Release Record (ERR) program was a relatively late edition to the Engineering programs. It featured highly detailed printouts for HP LaserJet printers, and less detailed printouts for other printers. The ERR form was not nearly as complex as the ECP forms, but a continuation form had to be written also, with the program set to automatically print the continuation form when the number of line items becomes too great for the main form. The page count also had to be tracked, as in 'Page (Number) of (PageCount).' Like all such Engineering forms, the printouts were hand-coded.
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
The Configuration Status Accounting Report program, another early program, was based on a report that had been generated in a word processor. The report actually consisted of two reports, one following directly after the other. That is, the second one began on the same page where the first one ended. The length of the reports varied, depending on the number of items in the reports, so the second report did not start on a fixed position, but needed enough room on the page for at least the header and a reasonable amount of data. The report was in a table format and every item, including the titles and each individual field, was enclosed by lines, forming a grid. The report was hand-coded.
The only printer code related oddity was the expansion of the title into double-wide, bold, separated letters, to match the word processor report. While it was possible to send the printer such codes, and I did set the report up to do it, it was difficult to make such a thing truly portable without being able to test the action of other printers. I did later put in a variation for HP LaserJets, though.
DCN
The Document Completion Notification program was an Engineering program, similar to some of the others, but using its own form. It was one of the later ones, and I think also set up to print high quality HP LaserJet reports, something that required a lot of testing, since I had to hand code all of it. And, like the other programs, it could also use a dot matrix printer.
This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.
ICN
The Installation Completion Notification program was an Engineering program, similar to the Document Completion Notification program if I remember correctly, but using its own form. It was one of the later ones, and I think also set up to print high quality HP LaserJet reports, something that required a lot of testing, since I had to hand code all of it. And, like the other programs, it could also use a dot matrix printer.
This program was never described at my GeoCities site, and listed only the title. I had intended to describe it, but never got around to it.
TEC
The Temporary Equipment Change program was based on a pre-existing paper form. The form was simple enough that a separate HP LaserJet version was not needed, but the hand-coded report still contained some specific areas where the printout was altered if an HP LaserJet was used.
Early versions of the program printed a Ford logo on the report, as I worked for Ford Aerospace at the time. I wrote the logo in Turbo C, because dBASE III, used at the time, did not permit direct input of the necessary printer codes. The codes were for a dot-matrix printer that the Engineering department used back then.
The form featured a large central area, where the temporary equipment changes were listed and described. In order to allow easy entry on the screen, with a format approaching that of the printed form, the area was divided into four parts: upper left, upper right, lower left, and lower right. The fields were laid out in a table format, and validation clauses determined the next field to access, based on the keys that were used to exit the current field. If the edge of the display was reached, the screen automatically changed to display the particular section that the user was heading for, with some overlap of the displayed data, so that the user could see a fragment of the other screen for reference.
A complication of the display was that some fields were split. In such cases, an area of the field from the next or previous screen was displayed, but was not available for data entry on the current screen, because the user needed to see part of what was in the section of the field on the other screen, and because if the area was currently available for editing the cursor would be placed on it and not where the user had been typing. Choosing a specific field to be activated when the READ began was not enough, because the field was only partially shown, even with the read-only part included. If the user had the entire displayed area for editing, the hidden part on the other screen would not be part of the edit and the user might overlook it or not realize that some other data existed there, particularly if the hidden section was on the right. The field was split only at the display, where it was divided into separate variables, and not in the actual field in the DBF table.
Engineering Taskings
The Engineering Taskings program began as a way to organize Taskings written in FormTool. The FormTool Taskings were based on a pre-existing paper form. The Taskings program imported the ASCII file portion of the FormTool record, which FormTool saved as an individual file (the other portion, saved separately by FormTool in a file with data from other forms, consisted of such things as underlining and other formatting). The file was placed in a long DBF field in a series of records. Each record had another field recording the Tasking number, which was extracted from the file name. The list of Taskings could now be easily displayed, and the tasking itself could also be viewed and printed from within the program. because of the large size of the form, the viewing was divided into several different screens, which could be reached with the arrow keys.
A different program was written by someone else, where the Tasking could be created and edited within the program. Unlike the previous program, where the report was hand-coded, the form was printed from a FoxPro report form. Since FormTool was no longer used to make the report, this meant that the large underlined section at the bottom, for hand-written notes, became instead a large blank area, but the Engineering department accepted this. The Engineering department had various complaints about the new program, and although I intermediated with the programmer, he was unwilling to make any more changes. The program was eventually given to me, and I rewrote it. (Still no underlines in the printouts, though. If they accepted the printouts without the underlines, why bother implementing them now.)
The old Taskings-converted-from-FormTool program remained in use, because it held the older Taskings that had not yet been entered into the new Taskings program.
Engineering Drawings
The Engineering Drawings program was a very early program, initially written in dBASE III, and later rewritten for FoxPro. It recorded Engineering department drawings. It basically recorded the drawing number and title, and various other useful related data.
Engineering Release Record Program
The Engineering Release Record (ERR) program was a relatively late edition to the Engineering programs. It featured highly detailed printouts for HP LaserJet printers, and less detailed printouts for other printers. The ERR form was not nearly as complex as the ECP forms, but a continuation form had to be written also, with the program set to automatically print the continuation form when the number of line items becomes too great for the main form. The page count also had to be tracked, as in 'Page (Number) of (PageCount).' Like all such Engineering forms, the printouts were hand-coded.
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:03:00 AM
0 Comments:
Post a Comment
<< Home