Hierarchy of "shown" ?

Sorry for the long rambling post, but I’ve spent far too many hours trying to get this to work and I’m about to switch my website over to FORTRAN.

I’m getting intermittent BDOD (Black Dialog of Death) errors that seem to be related to code I have for filling WebListBoxes and WebPopupMenus. The errors are almost always like this:

Could not execute returned javascript: undefined is not an object (evaluating 'Xojo.controls['Ruxvp12i'].refresh')
I have a listbox embedded in a WebContainer, which itself is embedded in another web container. I instantiate these at runtime, like this:

newPageContainer = New somethingsomething // where somethingsomething is a web container newPageContainer.EmbedWithin(self, x,y, w, h) newPageContainer.Visible = true

This is not the way I had it originally; originally I put all the containers on the page in the IDE and just manipulated their visibility. That caused many, many more BDOD errors, so I started doing it this way.

Because the code execution path never changes yet the errors only happen every so often, I believe this is a timing issue related to the existence of a control on the page.

So my question is: when, exactly, is it safe to do things like fill a listbox or a popup? I had been doing it in the Shown event of the relevant object (i.e. the Shown event of a listbox fills the listbox).

In a hierarchy of web controls (including containers), does the outermost “Shown” fire first, or the innermost? I’m ok refactoring all the code to put the listbox filling and other initializing somewhere else, if someone can tell me what the right place really is.

I have seen others (such as @Bob Keeney ) suggest using a timer to fill these, but that seems like a poor workaround for what ought to be classified as a bug.

Oh, and just “one more thing”: the BDOD often (but not always) appears BEHIND the WebContainers, so it’s impossible to read it or click on either of its buttons. This also seems like not a Good Thing.

Suggestions are welcome. Thanks!

[quote=223087:@Charles Weger]I’m getting intermittent BDOD (Black Dialog of Death) errors that seem to be related to code I have for filling WebListBoxes and WebPopupMenus. The errors are almost always like this:

Could not execute returned javascript: undefined is not an object (evaluating ‘Xojo.controls[‘Ruxvp12i’].refresh’)[/quote]

Next time it happens open the developers tools and look at the controlID to see which control is affected. That can be significant.

+1

I have seen the same thing often. I don’t think Xojo has any control over the JavaScript BDOD Z-Order.

It’s always a listbox or a popup. The code in all those is largely similar in the Shown event.

This is the first time I can remember hearing about this. One of you should file a bug report so we can get that fixed.

In my applications I’m using only one page filled, as required, with containers.
The approach I’m using, and it works reliably, is for a container to keep track of its contents and generate a computed shown event only when all of the contained controls have generated their shown event.

Doing this, the shown event of a container notify that all the contents can be accessed safely without any timing issues: the app is in sync with the browser.

Keep in mind that there is only one control that must be handled differently: the WebImageView…
This control is ready only after the first PictureChanged event and not after the shown event (this event gets fired also if the control contains no picture).

Regards

If you fill a ListBox or a Popup in its own event, Shown should exist at that point. If you do things in other controls, chances are the undefined error comes from the fact that the control does not exist yet in the DOM.

Concerning the order of shown between controls, you may want to verify that with System.Debuglog in each, but I would not trust that absolutely. Each browser may have its own way of creating controls and AFAIK Xojo does not guarantee a particular order.

The only thing I have seen time and again is that the WebPage Shown happens after the control’s.

I would tend put the code in Shown, or in a Timer. It is possible in JavaScript to check if a control exists but then you would have to poll until it comes up.

<https://xojo.com/issue/41324>

Also a much earlier bug report here:

<https://xojo.com/issue/27892>

@Michel Bujardet said: [quote]“The only thing I have seen time and again is that the WebPage Shown happens after the control’s.”[/quote]

That has not been my experience. I wrote an app with two container controls, one which had a listbox and one which had two popups. On the main page was a single label. In each Shown event I wrote a message to the log.

As you can see from the log, the page Shown event fired first, before its children or any of the container controls.

WebPage open WebPage1 shown start WebPage1 shown finish Label on main page shown Container1 shown Listbox shown start Listbox shown finish Container2 shown Popup1 shown start Popup1 shown finish Popup2 shown start Popup2 shown finish Listbox filling finished App closing

I finally figured this out. I thought I had pulled all the code out of various “shown” events that affected other controls, but it turns out I had a WebSegmentedControl that, on Shown, was setting its ListIndex to 0. This in turn caused its Action event to fire, which then did some stuff to other controls in the container. That was the problem.

The moral of this story is, as Elmer Fudd would say: BE VE-W-W-WY, VE-W-W-WY CAWEFUL when putting code into the page or a control’s Shown event that might affect other controls. Control loading at runtime is unpredictable and you WILL get JavaScript errors if you do what I did.

Interesting ; it works reverse of Desktop somewhat. Thank you for posting your investigation. I never needed to do so.

As I suspected. Glad you found it.