Using JS to Clear a Widget's Bound Value

[David]

You're very welcome, I'm glad that we've gotten to the bottom of it. I know there are a lot of things going on with a UI like this and it's hard to see all the possible interactions that could be going on. Let's just shoot for a simpler example next time. :-). Ha ha.

The effects you've implemented in the screen are very cool, I did see the CTRL click row selection and I thought that was pretty slick. While looking at this, I did also notice what you were saying about it being 'funny' about where you have to click for selecting a row.

It's generally not, and I was wondering why this would be. I think it has to do with the text box being there. I think the click event is getting trapped on the text box for some reason and not getting through to the cell. I wonder if you could get around that by actually hiding the text box (visibility) property when not needed and just overlapping an output field behind it, bound to the same field.

You could perhaps bind 'visibility' to the same indicator and reverse the indicator formatting to show/hide them as needed. That might be kind of 'funky' in the designer, but maybe would give a nicer effect at runtime.

[David]

Another spin on that idea is maybe you could leave as is and having styling that is put on when you make the box 'read only' lower the z-index, that might also do it. Would be a lot better, if that works.

[DaveLClarkI]

While looking at this, I did also notice what you were saying about it being 'funny' about where you have to click for selecting a row.

Yep, I ended up having to leave extra space in the columns in order to give it somewhere to click. A nice solution to this "problem" would be wonderful. ;-) If the click could be made to bubble up through the text box that would be ideal. I found that double-click does bubble through the textbox but not the single click.

[David]

I had a look into it and found that the row selection processing is purposefully skipped when clicking on certain controls in the grid cells. The intention is that you can interact with the controls without selecting a row. I think there are cases when that is desirable. But if the control is read-only or disabled, I didn't see any reason it should do that. I adjusted it in dev. so that clicks on disabled or read-only controls will still trigger row selection. This change will go into our next update.

On another note, I also wanted to clarify my comment before about the script for the dynamic message overlay being 'overly complicated'. Of course, I should have explained what I meant by that exactly and offered suggestions in order for this to actually be helpful, rather than just sounding critical. I'm sorry if it came off that way -- it wasn't my intention, and at that point I was just focused on trying to solve the problem at hand.

Anyhow, I was confused on why the 'message source' widget was input-capable as I'd tend to use an output field widget for things like this. Are there cases (other than clearing) where it would need to give input to RPG? If not, this is one less bit of interaction between the program and the UI to worry about and it could be simplified quite a bit. I did see how the row click scripts are calling the same code to show messages and I saw that this was done by updating the 'message source' widget and then clearing it after. I understand that you are going for a general purpose utility here that can be driven by RPG (via onload event) or by any other coding that you might want to do in the browser.

One idea to simplify it is that you could have the 'msgSource' parameter accept the message text as a string rather than a reference to a 'message source' widget. This way, calls from 'onload' to bring in values from a widget bound to RPG field data would just pass the result of 'get()' rather than 'getObj()'. The row click scripts could then pass in their own strings directly to the utility, rather than having to update a widget first. There would also be no need, then, to clear the widget after.

Each render of the UI can be (and should be) thought of as a 'clean slate' from the browser's perspective. When you submit a screen to RPG and the program responds back, the rendering framework completely erases the previous screen, then paints the next one with the new data provided by the program. Absolutely zero state information is retained in the browser. The UI framework sees no difference between rendering a new record format, or re-displaying the same one. It's a complete wipe/fresh paint in either case. All state is maintained in the RPG program, which then just needs to take care to set the screen properly (as yours was trying to do) before each load.

The behavior with 'error messages' is very confusing, and it's easy to forget about. It happens all the time -- we are considering to default to checking the 'Enhanced Mode' when setting up new error messages in the designer.

Finally, I thought you might also like to know about these aliases that you can use in your coding:

Code: Select all

pui.get("widgetId"); // Same as: get("widgetId")
pui.set("widgetId", "value"); // Same as changeElementValue("widgetId", "value");

[DaveLClarkI]

Anyhow, I was confused on why the 'message source' widget was input-capable as I'd tend to use an output field widget for things like this. Are there cases (other than clearing) where it would need to give input to RPG? If not, this is one less bit of interaction between the program and the UI to worry about and it could be simplified quite a bit. I did see how the row click scripts are calling the same code to show messages and I saw that this was done by updating the 'message source' widget and then clearing it after. I understand that you are going for a general purpose utility here that can be driven by RPG (via onload event) or by any other coding that you might want to do in the browser.

Somehow I got the impression I had to use a text box -- don't remember why. Will an "output" field still allow JavaScript to set a value (see below)? Otherwise, no, it is not intended to ever send anything back to RPG.

One idea to simplify it is that you could have the 'msgSource' parameter accept the message text as a string rather than a reference to a 'message source' widget. This way, calls from 'onload' to bring in values from a widget bound to RPG field data would just pass the result of 'get()' rather than 'getObj()'. The row click scripts could then pass in their own strings directly to the utility, rather than having to update a widget first. There would also be no need, then, to clear the widget after.

Because it is a general purpose utility, it must be able to be called in much the same fashion every time even when under differing circumstances. I did originally have this function accepting plain text but changed it so that the caller didn't have to clear the message box themselves. However, if an "output" box will work for the onload event then I suppose things could be changed back to the way they were. I still don't see that this simplifies anything "quite a bit" when we are only talking about one line of code -- either in the function or when called outside of the onload event.

Finally, I thought you might also like to know about these aliases that you can use in your coding:

Code: Select all

pui.get("widgetId"); // Same as: get("widgetId")
pui.set("widgetId", "value"); // Same as changeElementValue("widgetId", "value");

Yes, thanks, I will use those. ;-)

[David]

When interacting with a widget using JavaScript, the widget needs to be a text box only if you want/need it to submit a changed value back to the RPG program. JavaScript can read text from an output field, and it can certainly clear the widget in the browser, too, if that is needed. But, the RPG code will not pickup on any changes made to an output field.

Anyhow, looks like we have gotten to the bottom of it now, and you can do it either way, of course. I just wanted to explain what I meant there. You're right -- having 1 extra line of code is not making the JavaScript code itself complicated, but that's not what I said. It was the interaction between the 2 (i.e. the RPG program seeming at the time to rely on the script clearing a widget) that I thought was adding complexity to the screen.

But, looks like you're all set now.

[DaveLClarkI]

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.

Yes, that took care of the problem. Thanks.

[David]

Version 4.8.2 was published today. This includes the small adjustment where the grid row selection will be processed when clicking on disabled or read only input fields in the grid. This should make the screen work a bit nicer. Also this update includes the feature to show grid context menus for tap/hold on touch devices. I think you were also interested in that for this screen.

[DaveLClarkI]

Yes, thanks. ;-)