errmsgid and unexpected results

[vrozen1]

Willie, there is probably nothing to help you except saying - do not be lazy and use msgsfl/msgctl to show the error messages. I work in a shop with strict policy of using ERRSFL. I saw many problems. They are not solvable - there is a way how it is work. The main things: it read screen first in a same way as it works when you press some CAxx attention key. So that mean it is not read your changes after error occurred. I think most of your problem connected to that fact. Vadim Rozen

[Guest.Visitor]

I'm working on a screen where the user will key in one of several possible search arguments to bring up a pick list. To make it simpler, lets call the arguments e-mail and name/zip. I'm lazy, so I used the errmsgid keyword on the e-mail and name/zip fields. Each is conditioned by a separate indicator and uses the same indicator as the response indicator. The logic is pretty simple. Try to build a pick list. If no records are written to the subfile, build the error message text and turn on the error indicator. The name/zip error checking works fine. Every time the attempt to build the pick list fails, the message appears on the message line. The e-mail argument only works if the first e-mail argument entered gets no hits. If the error occurs after a successful attempt to build a pick list based on the e-mail argument, nothing happens. I ran it in debug. The indicator goes on when the error occurs and stays on right up the exfmt. I put a text literal on the screen that only appears when the error indicator is on. That works just fine. The code for calling the two error messages is (famous last words) identical. The DDS for the screen fields is identical. I'm going nuts. I can always put the error on the screen a different way, but I really like using ERRSFL and system error checking because I've never had to spend much time on it 'til now. Any ideas?

[Guest.Visitor]

The "ERR*" keywords behave a bit oddly (in my opinion). Here's an excerpt from the manual ... "The following apply to ERRMSG: When an ERRMSG or ERRMSGID keyword is in effect, no processing other than the processing for these keywords is performed for the record. If neither keyword is in effect, the record is processed in the normal manner. When the RMVWDW keyword is active, error messages are not displayed. ERRMSG and ERRMSGID are valid for output-only, input-only, or output/input fields. These two keywords cannot be specified for a constant, hidden, program-to-system, or message field. For input or output capable fields, ERRMSG and ERRMSGID are in effect only if the record containing the field for which they are specified is already on the display. ERRMSG and ERRMSGID cannot be specified in a subfile record format (SFL keyword specified). To display error messages for a subfile, see "SFLMSG (Subfile Message) and SFLMSGID (Subfile Message Identifier) Keyword for Display Files". ERRMSG and ERRMSGID are ignored if the variable start line number (SLNO(*VAR) specified) has changed since the last output operation. If you specify ERRMSG or ERRMSGID, you should also specify RSTDSP(*YES) on the Create Display File (CRTDSPF) or Change Display File (CHGDSPF) command. Otherwise, data on the display can be lost if the file is suspended. On an output operation that causes the display modes to be changed, ERRMSG and ERRMSGID are ignored. " I tend not to use them and prefer the SFLMSG methods. BUT ... if you do want to use them, here's what I used to do (it's been a while). Issue a WRITE to the format containing the ERRMSG field before doing the EXFMT. I know it's messy but I believe that gets it working because is satisfies this statement ... "For input or output capable fields, ERRMSG and ERRMSGID are in effect only if the record containing the field for which they are specified is already on the display". Good luck!