Client Side Error Message with Web App

[Michel_Bujardet]

@251705:@Ralph Alvy

Though I already deleted that errors.log file, I remember it only saying there was a JavaScript error, and nothing else. I’ll see Phillip at 1701 Software can undelete it for me.

I am not talking about the error.log, but about the message that pops in the browser, the black dialog with two boxes on top of each other and the two buttons “send” and “do not send” you talk about in your OP. The top box has a more informative message, and also lists the JavaScript code in which the error occurred.

[James_Sentman]

@251714:@Phillip Zedalis

Both of those would be altering UI. Anytime you change any UI properties the web app sends javascript down to the client. If for whatever reason the UI has not instantiated that control yet or some other critical error that message is shown. So the trick is to make sure the controls have been ‘Shown’ before sending updates to them.

This is exactly what I was complaining about So I have no choice but to send my controls to the browser in the default state and have them appear with all my labels saying things like “unconfigured” or “default” or just blank and then fill them in after that in the shown event. I can also send them all invisible and then set them up and make them visible in the shown event but this also is so much slower appearing to the user and just sloppy.

The open event should be able to be counted on to happen BEFORE the control is sent to the browser so that I can set any of the properties safely and then have it appear in that properly configured state.

For container controls you can do initial setup between instantiating the new control and embedding it and that will allow you to setup the initial state of the controls. But not everything works properly and the size of the control will not be correct so you can’t use the width and height to calculate offsets and such.

[Ralph_Alvy]

@251754:@Michel Bujardet

I am not talking about the error.log, but about the message that pops in the browser, the black dialog with two boxes on top of each other and the two buttons “send” and “do not send” you talk about in your OP. The top box has a more informative message, and also lists the JavaScript code in which the error occurred.

Ah. If it happens again, I have every intention of capturing the error details that way.

[Michel_Bujardet]

@251832:@James Sentman

So I have no choice but to send my controls to the browser in the default state and have them appear with all my labels saying things like “unconfigured” or “default” or just blank and then fill them in after that in the shown event

You can also make them invisible in the IDE and turn them visible in Shown.

[Tim_Parnell]

@251832:@James Sentman

The open event should be able to be counted on to happen BEFORE the control is sent to the browser so that I can set any of the properties safely and then have it appear in that properly configured state.

Technically it is, and that’s why you’re having the problem. When you’re setting the properties, Xojo is sending JavaScript to change them in the browser; but because it doesn’t exist problems arise.

OPEN CONTROL ARRIVES IN BROWSER CONTROL IS READY SHOWN

I guess a solution could be for Xojo to internally determine that if the control hasn’t arrived in the browser yet that properties should only be server-side and be changed for the initial send-to-browser. But that could lead to latency issues where you set properties while the control is already on the way to the browser and Xojo doesn’t send the JS to update.

Three options for now:

• Control stays hidden, set properties in Shown and then set to visible. (by the way, that’s how the WebSDK recommends it for custom controls)
• Send control visible with placeholder text like, “Loading…”
• A general overlay loading screen that you hide once all the controls have received their proper labels.