Thursday, April 26, 2018

Programming text screens in Priority

In Priority, there is a special type of form which contains 'HTML text' - this form is like a mini-text editor; the text can have different fonts, different sizes and different colours. As programming such a form is quite difficult, there is a procedure which automatically creates such forms. The new text form has a default name of the parent form + text; for example, the text form for PART (i.e. parts) is called PARTTEXT, and the text form for ORDERS is ORDERSTEXT. Unfortunately, if a main form already has a text form, the procedure will choke and announce that a new text form cannot be created. Thus one has to create the form (and first define the table which will store the text) manually.

The table can be created in about a minute, and creating the new text form should take between ten to fifteen minutes, where one has to copy several triggers from an existing text form. Of course, the triggers have to be edited to reflect the text form's name, but this is simple.

As I was asked to add two new text forms to the ECO screen, I defined two tables (TEST_ECOTEXT1 and TEST_ECOTEXT2) then proceeded to define the screen TEST_ECOTEXT1. This took about ten minutes to do, but when I 'built' (i.e. compiled) the form, I was presented with a series of error messages which didn't make much sense, as they referred to a non-existent screen, TEST_ECOTEXT. 

After wasting an hour trying to figure out what the problem was, it occurred to me that maybe the table name (and hence the screen name) should end with 'TEXT'. I changed the table's name and the form's name to TEST_ECO1TEXT, compiled ... with no errors!

Moral of the story: the name of all text tables/forms must end in TEXT!

Edit from a few months later: my friend Yitzchok came across a similar problem which led us to conclude that my conclusion above was wrong. The real conclusion seems to be 'The name of all tables/forms must not end in a DIGIT'.

1 comment:

Yitzchok said...

I agree that names ending in TEXT will certainly work. And I don't rule out that the form name might have to end in TEXT in order to magically turn from a regular list-of-lines form to the HTML editor (I don't remember whether I ever created a form which wasn't named ...TEXT).

Also I don't see any reason why the table name should have to end in TEXT, or to be the same as the form name.

So... I'm far from convinced that those are the reasons for your problem in this case.

Rather, I think you'll find that there is no form anywhere in Priority whose name ends 1.
The reason is that 1 (as we often see expressed in ":$1." versus ":$.") is a magic name for . As a result, you simply can't call a form MYFORM1, or at least actually use it, because any attempt to refer to it will be perceived as an attempt to address the original values in MYFORM. The error messages you saw seem to reflect exactly that pattern.