Using JS to Clear a Widget's Bound Value

[DaveLClarkI]

It's the <= " " part that baffles me. You are looking for strings that are less than blanks? Is an empty string less than a blank? Or more? How can you even quantify what an empty string will be?

This is just a programming style issue. Meaning: I don't like equal comparisons for this type of stuff. I've been bit, before, with such comparisons. Yes, both an empty string and a string with white space in it will be less than a string with a single blank. Unequal length strings are blank-extended in order to perform the comparison.

[David]

I found why the screen is not behaving in the way you're expecting it to.

Your scripting is fine to clear the widget, and that all does happen as it should. However, you have buttons on your window (i.e. the Help button) that, when used, prevent your program from receiving any updated information from the display.

So after you display your message text and clear the widget, the user then clicks on the Help button which has the 'bypass validation' property turned on. See the property help text on that one! So then the screen submits to your RPG program and no update to the INFO_MSG field is sent to your program. Your program then spits out the old value on the next display.

The 'bypass validation' property is used to provide an effect similar to a command attention key on the green screen. It's appropriate for exit, cancel buttons, etc. Since the program is not going to get any changes to the screen data, ALL data integrity and validation checks are bypassed.

If you want to avoid client-side validation (i.e. the Validation category of props) but still send updated information to the program when the button is pressed, there is a 3rd option for bypass validation called 'send data'. In this case the validation is skipped, but since your program will get changed data, the data integrity checks (i.e. valid numbers, dates, etc., have been entered) still must be performed.

In my humble opinion, though, the interaction between the script and the screen is overly complicated. Seems like the program should just clear the INFO_MSG field before any redisplay, rather than expecting the browser to do it.

[DaveLClarkI]

In my humble opinion, though, the interaction between the script and the screen is overly complicated. Seems like the program should just clear the INFO_MSG field before any redisplay, rather than expecting the browser to do it.

That is exactly what the program does. Immediately after receiving control back from the screen I/O wait, the program clears the INFO_MSG field. Plus, as I mentioned before, this problem does not occur for the underlying main screen even though that HELP button is coded in exactly the same manner. So, I would appreciate it if you would look a little deeper. Thanks, very much.

[David]

I did see that the program is putting out the data 'Update completed' in the field INFO_MSG in the window record format when it redisplays after pressing the Help button. Of course I didn't delve into the program source code itself, but I do see in the browser's network request monitor that it's coming back from the program.

I'd suspect something in the RPG program is putting the message back before the window is redisplayed.

[DaveLClarkI]

I ran it through debug and INFO_MSG is blank when the program writes the record formats back to the workstation. Again, very strange that the same problem doesn't happen on the main screen -- only on overlay windows. The RPG program for the overlay window is a copy of the RPG program for the main screen with only the names of the database fields and record formats changed to fit the different circumstance. The logic flow is exactly the same.

[DaveLClarkI]

In my humble opinion, though, the interaction between the script and the screen is overly complicated.

It is not "over-complicated" to add one line of JavaScript to clear the message field.

With all due respect (and take my word for it that that is plenty), when you don't know the full story it would be good thing to think there must be a good reason why a thing is done the way it is done. In this case, it is done that way because the same function gets called as part of the grid's onrowclick event and many grid rows can get clicked without making a round trip to the server. I don't want any message text left in that field -- just in case another programmer comes along and makes a change without knowing the full story, either.

Try selecting additional grid rows (with Ctrl key) one at a time and see what happens.

[David]

Ok. So the question is really, then, why does the new output data from the program not get sent to the screen in this case?

The answer is the 'error message' property on the record format...

This is modeled after the ERRMSG and ERRMSGID field-level keywords from DDS. Also the SFLMSG and SFLMSGID keywords (record level) are similar. In our DDS conversion, these keywords translate directly into these properties. The keywords come with some confusing behaviors, see here:

http://pic.dhe.ibm.com/infocenter/iadth ... tdfems.htm

See the 2nd paragraph under 'Conditions Occurring During Message Display'. Our Handler emulates this behavior for accurate performance of converted programs. For anything developed new, I would recommend turning on the 'Enhanced Mode' check box on the Error Messages dialog. This will do away with the confusing behaviors. See the tool-tip text for the check box.

[DaveLClarkI]

See the 2nd paragraph under 'Conditions Occurring During Message Display'. Our Handler emulates this behavior for accurate performance of converted programs.

Yes, I'm aware of that behavior but would also like to know why it isn't biting me the same way in the case of the main screen? Thanks.

[David]

The main screen doesn't have 'bypass validation' set on the Help button. So when you click it, the change made to the field by your 'changeElementValue()' call is submitted to the server and the record buffer for the screen is updated.

Note that I can't actually run through all the steps on the main screen (Help button calls AC150CL, which I don't have), but I can still see that this is what is happening. I can see the property is not set on the button and I can see the browser post the updated value (empty string) back to the program in that case.

Hopefully this clears it up.

[DaveLClarkI]

Well, that explains it. Thanks for jumping through all these hoops to help me understand. The help button on the main screen did have that originally, but that screen went through a lot of iterations (rearrangements, deletions, and recreations in the learning and look-and-feel decision-making process) and it would be easy to lose some settings between iterations. Thanks, again.