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'.

No comments: