During a few testing sessions of a new Web app, I got an error message that showed me a bunch of text and gave me two buttons: “Send” and “Do not Send.” I had thought this was a server side error message and asked Phillip over at 1701 Software what would happen if I pressed the Send button (would it go to him or would it go to the email address he has on record for me). He said he knows about this kind of error message and has no idea what it is, and that it’s client side, not server side.
Anyone know anything about this?
It sounds like you’re talking about the UnhandledException error dialog. From the User Guide:
[quote]The default error dialog displays information about the error and provides a field for users to add additional information if App.UnhandledException is not implemented or returns False. This information is written to an errors.log file alongside the web app. If the dialog that is displayed, if the user clicked “Send” you can also get the information in the WebSession.JavaScriptError event handler so that you can log it yourself.
Remember, if this event handler has been called and you return False (the default) it means your entire web app is going to stop running. Return True to hide the default error dialog and prevent the web app from quitting.[/quote]
It’s a JavaScript error. Xojo catches them and displays them like that. I assume that if you press Send, it goes to Xojo staff.
I see them a lot when building custom controls as I tweak things to work friendly with Xojo.
The text in the box is very important, it tells you what part failed. If you’re using custom controls, copy that entire blob, and send it to whoever made the control. If you’re not using custom controls, press the Send button on that dialog. If you can reliably re-create the issue, file a bug report and attach the project with your process for causing the bug. It will help everyone, as Xojo can try to fix it.
Very interesting. So it sounds like it’s a Xojo bug being exposed, as opposed to a problem with what I have done creating this Web app. I admit that I did find an errors.log file alongside the app the other day and read it. It just reported that there was a Java Script problem without any details about just what that problem was. I deleted it.
I’ll read that documentation Paul suggested and change the app so that I get that info logged.
It sounds like, according to the documentation I have yet to read (WHAT?) it could be a bug in your code too.
Be on the lookout.
in my experience its impossible to completely suppress that error message on the client. The documentation that Paul quoted implies to me that the popup only happens if the unhandled exception event is unimplemented or returns false but this isnt the case. That popup happens regardless. If you click send then it goes to the javascriptError in the session object if its implemented and to the desktop file if its not. Then the client gets a thank you for helping us solve this problem message for a few seconds and the web page reloads.
even without writing web control plugins or manually messing with the execute javascript command there are several ways you can make this happen. MOST of the time Im able to setup controls in their Open event and have them display the proper data when they are displayed, but not always. Some controls, especially the canvas control, seem to not like this at all and require that you show them first in the state they were created in the IDE and then update them, which is extremely frustrating as some controls show properly at load and others show default text and then have to be updated in the Shown event to show the actual data that you wish to.
When a control is being sent to the browser or not is the most common way that Ive seen these lately. It SHOULD be possible for me to set any property of the control in its open event, which is supposed to happen before the control is sent to the browser, so I can set its initial state. This doesnt always work. Im currently watching a couple of my webCanvas based controls as they are currently the last control I use that cant be setup reliably at open. Im thinking that the canvas control may not do the proper controlAvailableInBrowser check, but I cant duplicate it reliably enough to make a bug report yet.
Select all the text in the top box of the JavaScript error black box. Everything is in there.
If you have no used any JavaScript in your code, the most frequent reason for this is to try and access a control in its open event, or another control, as they are probably not yet fully created in the DOM.
The solution is usually to place the code in the WebPage open event instead, which happens after that. Or even in Shown, when you are sure everything is ready.
What we need is a spec on when we can change the controls properties BEFORE it is sent. Its not the same for all controls and when you add in things like Container controls it gets even more complicated. A controls OPEN event should happen before its sent to the browser. It sometimes does. For example if I want to display a WebLabel with the text decided upon run rather than at design time, when can I set it to have it be safely in the browser? What if the webLabel is on a container control? I dont want the web label to display first as blank or unconfigured or something that is setup at design time and then be changed in the Shown event. That makes your interface first show up empty or with placeholders and then change. We need a reliable way to setup the controls before they are sent to the browser. Open often works, but not always, if you find a place it doesnt reliably work make a bug report please.
The crash report ends up in errors.log in your app’s folder…don’t know if it goes to Xojo - hope not as it has some very unkind messages in it. The errors.log itself is completely pointless. The javascript framework is quite unstable at times - it mostly happens for us when a webdialog is being closed (wait for a long time, sometimes it returns to the page, other times it crashes.
[quote=251644:@Michel Bujardet]Select all the text in the top box of the JavaScript error black box. Everything is in there.
If you have no used any JavaScript in your code, the most frequent reason for this is to try and access a control in its open event, or another control, as they are probably not yet fully created in the DOM.
The solution is usually to place the code in the WebPage open event instead, which happens after that. Or even in Shown, when you are sure everything is ready.[/quote]
I have no JavaScript in my code. And the App.Open event has only two things. Phillip Zedalis’s timer code to allow CGI file updates to be easier, and a method that loads the SQLite database file.
If you could post the javascript error log, it would probably tell what is going on. Make sure to copy all the content of the box.
Right, but the code that Xojo sends to the browser does have javascript.
Double check to make sure you have no code in the Page Open event or any Control.Open events. This will nearly 100% of the time cause javascript errors. Use the Page.Shown event instead.
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.
[quote=251696:@Bob Keeney]Right, but the code that Xojo sends to the browser does have javascript.
Double check to make sure you have no code in the Page Open event or any Control.Open events. This will nearly 100% of the time cause javascript errors. Use the Page.Shown event instead.[/quote]
So it sounds like I should have no code in my App.Open at all. I don’t see an App.Shown event, so I’m not sure where else to put early initializing code, like starting Phillip’s famous timer code and connecting the database. Would I, instead, move them to the Session.PrepareSession event, and just start the timer if it hasn’t already started and connect the database if it hasn’t already been connected?
The timer code can stay in the App.Open event. What you don’t want to put in any App/Session/WebPage/Control Open event is anything that manipulates UI state. Those types of things have to go inside the Shown event.
By “manipulate UI state”, does that include setting values in displayed fields? Or does it only refer to altering Properties of the UI, like those seen in the Inspector? I have a feeling I’m supposed to do even the former in the Shown event.
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.
I’m pretty sure I get it now. Thanks, Phillip. I have some minor rewriting to do.
Just want to make sure about this. By altering UI, I assume that would not include setting a Property value that happens to be tied to that Session/Page/Control object, because that has nothing to do with how that UI displays in the browser. E.g., my Session.Open event parses Session.URLParameter and, in the process, sets various Session Properties for later use.
Please bear with me here. I’ve never had to deal with this distinction developing Filemaker solutions.
IF they are properties you added to the control then it should be fine as those properties only exist at the server.
Session object should be okay because if its been instantiated than the server should be able to manipulate it regardless of the UI state. However say for a WebLabel you don’t want to change it’s values until it’s been ‘Shown’ first. Otherwise Xojo is going to send a command “Change the value of the label” and the javascript on the client is going to error out because it has not created the label yet.
Some of this you only discover after you have deployed on the Internet. When testing locally you have no latency so objects are created on both server (IDE) and client (browser) instantly. With latency and network traffic things don’t happen so quickly so sometimes Javascript events can be sent to the client before the Shown event actually occured.
This has been a very informative thread for me. I ended up realizing that much of what I really needed to pay attention to was the description the IDE shows for each Event Handler. The Open handler clearly says it fires before the browser is fed, and the Shown handler fires when the browser is loaded. I really didn’t pay attention to the significance of the difference between the two handlers.
Anyway, I moved UI-related code out of the Session.Open handler and placed it in a Page.Shown handler and all is testing fine. The previous way I had it only raised errors a few times a while ago and never again, but I trust this way of segregating the code now that I finally understand the two event handlers better.