FWD » Core Development » Base Language

Constantin,

Consider this:

def var txt1 as char.
def var txt2 as char.

update txt1 format "999" 
       txt2 format "x(3)" 
       editing:
          readkey.
          apply lastkey.
       end.

The "999" character format requires that there be 3 numeric digits in the resulting edited value. If not, then even in the 4GL we get an error.

The problem here is that when we type the 1st digit char, the editing block gets invoked, the char is read via readkey and then we apply it to the client. The following is the call sequence that causes the problem:

ThinClient.apply ()
ThinClient.getScreenBuffer ()
FillIn.getValue ()
FillIn.update ()
StringFormat$CharBuf.checkFormat ()

At the very end of the apply, we update the screen buffer to send the edited results back to the server. As part of that, we call update() which checks the validity of the data based on the format string. The problem is that we are in mid-edit here and the overall result can't possibly ever pass this check. So the code generates an error 631 and an error 629 and forces the cursor to the first char position in the field.

The 4GL has no such behavior, it only validates against the format at the very end of the edit (when you try to leave the field via TAB, ENTER or F1).

I suspect this has been broken for a while (forever?).

Thoughts?

Thanks,
Greg

Code Review ca_upd20150128a.zip

My only concern is with the use of checkFormat() instead of validateFormat() on LEAVE. The 4GL does indeed generate a single error 630 instead of the combination of 631 and 629 for character. In addition both DateFormat and DatetimeFormat have some very specific processing that is implemented in validateFormat() which will no longer be executed on LEAVE.

Other than that, the changes are good.

Greg Shah wrote:

Code Review ca_upd20150128a.zip

My only concern is with the use of checkFormat() instead of validateFormat() on LEAVE. The 4GL does indeed generate a single error 630 instead of the combination of 631 and 629 for character.

I think we are going into murky waters again. Looks like validation is done only if the buffer changes. Use this:

def var txt1 as char.
def var txt2 as char.

display "aaa" @ txt1.

set txt1 format "999" txt2 format "x(3)".

and press ENTER twice: this will allow a LEAVE at txt1 (first ENTER) and the second ENTER (frame LEAVE?) will force the txt1's screen-value to be validated against the format, showing a 630 "character a at position 1 must be digit." and a 143 "unable to evaluate field for assignment" message.

If you change the text to "aa1" and press ENTER, it will show you only one 630 error. This is different from the case in note 1, when UPDATE is used with an incomplete value, like "12" instead of "123" - it will show both 630 and 629 error messages.

I think 629 error appears only if all chars are valid or blank, but the field is not fully input (some chars are blank).

In addition both DateFormat and DatetimeFormat have some very specific processing that is implemented in validateFormat() which will no longer be executed on LEAVE.

Yes, I missed this.

With this in mind, I'm still trying to determine why both checkFormat and validateFormat APIs in DisplayFormat$Presentation were needed...

This is going through runtime testing now.

CTRL-C passed, MAIN part was killed and restarted, as after ~5 hours was still running.

Code Review ca_upd20150129b.zip

I'm fine with the changes.

Greg Shah wrote:

Code Review ca_upd20150129b.zip

I'm fine with the changes.

Passed runtime testing, released to rev 10728.