LinkExchange Network

This area is for the pursuit of new PC technologies I am interested in. I will khronicle the directions my research takes me, dead ends as well as yellow brick roads, since you can learn much from mistakes.


Corollary to Murphy's Law: "Everything takes longer than you think."


Site Map

Log Index
Previous Investigations Log Entry
Next Investigations Log Entry

Konsultant's Log
Cyberdate 09.20.1997
Abusing WordPerfect to produce an "Electronic" form Part II


At the end of Part I of this series of tech investigations, we had placed, and configured, two text boxes on our form as shown below.

Notice of Commencement Form 2 screen shot

Now, we are ready to begin adding text and the underlined "fill-in" areas (fields). The underlined fields were the big problem. In WordPerfect and other word processing applications, when a user types text into a document, the text to the right of the cursor is either replaced (typeover mode) by the text being typed, or moved further to the right (insertion mode). Either way, the form could be quickly destroyed by the typist if s/he were not a WordPerfect expert. For the form to work as intended, restrictions on where the user may type the fill-in text must be enforced.

First, I tried to place the lines precisely on the page as graphics. This did not work. Although the lines would stay exactly where they were placed, the rest of the form text would not stay anchored as the user typed.

Another Dead end experiment: I also tried "Floating Table Cells". This too was abandoned after considerable effort trying to make it work, including using a separate data-entry table outside of the form to avoid the cursor-positioning hassle that would be experienced by the User. I realized this was not the appropriate method for what I was trying to accomplish. It was too "Rube Goldberg".

After some more "scrambling around", I realized the key to this dilemma was the use of WordPerfect's "Tables" features. In fact, the rest of the form will consist entirely of a series of tables. The proper formatting of the tables will protect the form's formatting and limit the typist to the "fill-in" fields when inputting data into the form.

After learning more about the Tables Features, I came to the realization that a second table for data entry would not be necessary, and that I could protect table cells (cell locks) so that the cursor would "bypass" them during data-entry on the form itself. This would allow the User to "TAB" from one data-entry field to the next without destroying the form, while filling in the form in a "natural manner" similar to the way they were now doing it on a typewriter. This solution was elegant enough to be implemented without further delay.

Designers, whether they be software programmers, architects, industrial engineers, etc. always seek the "elegant" solution which can be described as "beauty of simplicity", "less is more", etc. The paperclip is an elegant solution, for example, and everybody wishes they had invented it.


To avoid damage to the document produced in Part I of this investigation, it is saved under a new name for our table experiments. Each "line" of text on our form will be a separate table.

STEP 1: The 1st table The first line "This Instrument prepared by:" will be a table consisting of a single, locked-cell. The cursor is positioned at the upper left corner of the form (after the second text box we placed in Part I).

Press the Function key "F9" to bring up the "Font" dialog. Choose "Arial" under "Font face", "Regular" under "Font style", and "9" under "Font size", then click the "OK" button. This will give us the "helvetica" style text we need for the rest of the form.

Under the "Table" menu, choose "Create" and in the resulting dialog, pick the "Table" radio button and enter "1" in the both the "Columns" and "Rows" fields. Click the "OK" button and the following single-cell table will be produced next to the text box created in Part I:

Create 1st table screen shot

Now, type "This Instrument prepared by:" in the table cell. With the cursor still in the cell, click the "Table" menu and choose "Format". In the resulting "Properties for Table Format" dialog, under the "Cell" tab, in the "Justification" section, choose "Left" justification and uncheck the "Use column justification" box. In the "Cell attributes" section, check the "Lock" checkbox. In the "Alignment" section, choose "Top" Vertical and "No Rotation" Rotation. In the "Diagonal lines" section, choose the "None" radio button. Your Cell tab dialog should resemble the screenshot below:

Table Cell Format Screenshot

Next, under the "Column" tab, in the "Alignment" section, choose "Left" Justification and the "Position from right" radio button with 0" in the input field. In the "Column width" section, type 5.31" in the "Width" input field and check the "Fixed width" checkbox. In the "Column margins" section, type 0" in both "Left" and "Right" input fields. This will give you the Column tab dialog screen depicted below.

Table Column Format Screenshot

Then, under the "Row" tab, in the "Lines per row" section, pick the "Single line" radio button. In the "Row height" section, choose the "Fixed" radio button and type 0.147" in the input field. In the "Row margins section, type 0" for both "Top" and "Bottom" input fields. All checkboxes in the "Row options" section should be unchecked. Your "Row" tab dialog should look like the one below:

Table Row Format Screenshot

Last, under the "Table" tab are the same "Alignment", "Column width" and "Column margins" sections found under the "Column" tab previously and they should be filled in with the same values. In addition, in the "Table position" section, choose "Left", and in the "Table Size" section, type "1" for both the "Columns" and "Rows" input fields, if not already indicated as such. At the bottom of the "Table" tab, the "Auto row insert" checkbox should be unchecked. The "Disable cell locks" checkbox is currently checked, but should be unchecked when table editing is finished so that the table will be protected from user-manipulation in the finished form. The "Table" tab dialog is shown below:

Table Table Format Screenshot

Click the "OK" button. As you may have come to realize, there is some overlap in the table formatting dialogs above. I have not researched which settings might take precedence over others, and which ones may be unnecessary. I only know at this point that these settings produce the effect I wish to achieve in the form for the main body of text on the form.

Highlight the table again, and, from the "Table" menu choose the "Lines/fill" menu item. In the "Properties for Table Lines/fill" dialog that appears, click the "Table" tab. Change all the settings to be "None" or "Off" so that the "Prevue" square is blank as indicated in the screenshot below. Then click the OK button.

Table Lines/Fill Properties Screenshot

These settings will make the table lines in the printed form "invisible". They will be invisible in WordPerfect v6.1 for Windows as well. In WordPerfect v7.0 for Windows 95, the hidden table lines will display as dotted lines. Our first table should now look like the screen below:

Partial Form Screenshot

Doesn't look like much for all that work, does it? I would be crestfallen if I had to make all the rest of the one-line tables the same way, but we don't have to go through all that drugery. This first table will be "copied" to the Windows "Clipboard" and "pasted" into the form below it for the next one-line table. A few editing changes will be made to the "pasted" table, and then we can create the third table using the same "copy 'n paste" method. Using this paste-up method, we only have to make a few basic table templates and, then, the rest of the form creation will go much more quickly.


Heck! This time we didn't even get to "STEP 2". We'll cover that next time. The next one-line table in our form will have one protected cell for the form text and one data entry cell for the user to type into. This project has taken me so much time, and I've stretched it out so long that I'm ashamed to charge the Client even a nominal fee for it. I'll likely end up giving it to them to restore good will lost due to my tardiness. Put this one in the "No good deed goes unpunished!" category.


Site Map

Log Index
Previous Investigations Log Entry
Next Investigations Log Entry

LAROKE Microcomputer Consultants
155 East Boca Raton Road
Boca Raton, Florida 33432
(561)368-0659 (Tel & Fax)

Issued Saturday, September 20, 1997

copyright © 1997 LAROKE Microcomputer Consultants all rights reserved