When you use the standard UNIFACE form (see Screen Shot 1) for maintaining messages in an application library you will find that it is not possible to search for existing messages using the contents of the TEXT field. You can only search using Message Name, Language and/or Description. When you want to search your message library to find the identity of a particular message this can be very frustrating if all you have to go on is what may be in the text of the message.
Screen Shot 1 - UNIFACE form for maintaining Messages
A lot of developers use the Description field of the message entry to hold a summary of the message text, but as this field has a maximum length of 25 characters it cannot hold much. If words are shortened to fit then this makes searching for particular words that much more difficult as the same word may have been shortened in different ways, or may have been excluded completely if there was no room for it. It also makes a difference if the Description field is entered using a mixture of upper and lower case as any search profile is case sensitive.
One solution would be to follow the advice given in a sister document called Browsing for Messages in your Application Library, but this involves extracting your messages into an external XML file and then viewing it with a web browser using formatting instructions in an XSL file. If this is too long-winded for you then you might like to know of the method that I have been using for many years. I find it easier to search for messages if I follow these very simple rules when entering data into the Description field:-
As I use the message file to hold different types of text which are to be retrieved at run time (e.g. form titles, hint text, field labels, button text, etc) I use a different prefix letter in the Message ID field to identify the type. I can then use the Description field to classify each message in an alternative manner. Table 1 below shows how I use these two fields.
| MESSAGE ID | DESCRIPTION | Comments |
|---|---|---|
| B_<formname> | <formname> | Button text for NAVIGATION buttons, where <formname> identifies the form which is activated by this button |
| B_<action> | <action> | Button text for ACTION buttons, where <action> identifies the action performed by this button, e.g. OK, Cancel, Close, Clear, Retrieve, Add, Delete, Store |
| H_<action> | <action> | Hint text (for action buttons) |
| H_<formname> | <formname> | Hint text (for navigation buttons) |
| H_<fieldname> | <fieldname> | Hint text (for screen fields) |
| L_<fieldname> | <fieldname> | Field label, for a standard label applicable to all screens (this should be set as the default value for the field label within the Application Model) |
| V_<fieldname> | <fieldname> | Valrep list associated with field <fieldname>, e.g. radiobuttons, dropdownlists, etc |
| M_nnnnn | see Note 1 | Message (there is no distinction between errors, information or warnings) |
| M_<formname> | <formname> | Message to appear inside a form, where <formname> identifies the form |
| Q_nnnnn | see Note 1 | Question (message requiring a response) |
| R_nnnnn | see Note 1 | Possible Responses to Question (where it requiring more than YES or NO) |
| T_<formname> | <formname> | Form title, where <formname> identifies the form |
| trigger mnemonic | TRIGGER | Replacement for trigger code |
You will see from this arrangement that I can now use both Message ID and Description to enter selection criteria for retrieving message file entries. This gives me a wider range of possibilities when I am searching for particular entries in my message file:
Where a group of entries share the same value for Description it means that all those entries will be retrieved when that description is used as the search profile. However, it is much easier to browse through half a dozen entries than the entire contents of the file.
I hope I have proved that with a bit of thought you too can make it easier to search for particular entries in your message file. So by being able to quickly verify that a message exists you don't cause confusion by creating a unnecessary duplicates.
Tony Marston
4th February 2002
mailto:tony@tonymarston.net
mailto:TonyMarston@hotmail.com
http://www.tonymarston.net