The framework could probably completely ignore errors where the call to Xojo.get just returns nil. Thats because a control got a message after the browser side framework deleted it or the page it was on. I cant immediately think of an example where this would be useful for debugging, but I understand if developers are cautious about just ignoring errors Perhaps a beta vs implementation mode where you can turn off such strict error checking for situations that are not errors?
I have to trap hidden events and not closed events since hidden happens right away but closed takes some considerable time after the page is left to happen. Perhaps that is a bug too, Im not sure yet.
This seems like something that shouldn’t happen in “normal” usage. The user clicks a button, which asks the server what to do, which tells the client to dismiss a view. The client and server should be in sync.
It’s an issue in the web framework where we don’t always check to see if a DOM element exists before calling a setter. I’ve been working to wrap these in try-catch when I find them, but there’s still a few places that do this.
I have found that web list boxes have this issue and raise errors that seem to have no real reason.
Just the same with listboxes, hide the first one while displaying the second. Of course this will not solve all cases, but maybe it helps someone.
Is there yet a solution? Will the new framework solve this issue?
One of the basic precautions to take is not to put any code calling other controls in controls Open event, as well as in webPage Open event. Most errors have to do with the DOM not being ready when one calls a control.
An easy way to go around that is to place the code a single webTimer on the page with period like 100ms. Since a webTimer is part of the controls, it won’t fire until the DOM is fully formed.
Another way is to put code in Shown, but you got to use a webPage boolean property such as deja, so you can do something like :
[code]If not deja then
deja = True
// Do stuff
That way the code executes only at the webPage opening, not every time it is shown.
I suppose you could try to trigger a server event to report the error if it happens and then know you had to resend whatever the command was…
That’s the catch… (could not resist). There is no way to suppress errors on a whole page, and even if there was, we would risk facing silent failures.
I trust Greg to continue is wrapping into Try Catch.
Of course he won’t know where to fix it without bug reports in Feedback…
Here’s what I do for my desktop app:
- In the HTML page that’s loaded you can have:
Then back on the Xojo side I have a handler for the status event. You can parse the string returned as the new status and then decide what to do with it.
I should have added that I don’t bother with try/catch for the most part. Only where it would be normal that a fail may occur, such as being told that a file is an SQLite database when it may not be. Then I go through a sequence of attempts to perform operations on the supposed database and see if they succeed, each of which is in a try/catch.
I wonder if that would work in a web app… I’ll give it a crack sometime.
My other problem, which I have mentioned elsewhere, is " the big black dialog of shame" is not responsive to mobile screen sizes. I wonder if by using Tim’s approach I can do away with Xojo’s dialog all together and offer the customer something that is viewable on mobiles and matches my colour scheme.