Undefined Control In Shown Event ?!


I’m having hard time searching through Feedback about this. So I’m posting the question here:

Are you aware that, in some cases (when dealing with dynamically embedded WebContainer so far), the WebContainer Shown event is called and by just changing, say, its Z-Index property, a Javascript error is triggered saying that this control is undefined ?

Exemple of this kind of error:

Could not execute returned javascript: Xojo.controls.A64ANFGg is undefined Source: Xojo.controls['A64ANFGg'].object().style.zIndex = '100'; Xojo.controls['A64ANFGg'].refresh();

In the Shown event of this control I just have:

Me.ZIndex = 100

How come a control can be ‘undefined’ while having its ControlID defined that even Javascript knows about ?!

The error is not always triggered. It happen on a page I refresh several times, sometime I get the error, sometime I don’t.

Is this an issue that you are aware off ? Or is this supposed to work properly and never happen ?

Because in my case this means I can’t thrust the Shown event anymore, which makes it impossible to predict this kind of error.

Any input/suggestion about this ?

JavaScript doesn’t know about it. That’s the error.

Is the ID in the JavaScript the same as the ID of the WebContainer? Or is it the ID of one of the controls on the container?

Sometimes you have to add a very small delay after it is shown to change any of the properties. Even something as small at 100 ms is enough. YMMV.

@ Daniel Taylor
The ID is the one of the WebContainer.

@ Bob Keeney
That’s exactly why I’m uncomfortable with this. This shouldn’t be as this means we can’t rely on the ‘Shown’ event ‘concept’ which is: “everything is there - not always displayed per say but - at least available in the DOM”.

I’m trying to find a solid repro-step for this, but unfortunately so far I haven’t been able to reproduce it in a systematic way. But there is definitively an issue here, not easy to pin point.

What’s funny is that if I set the ZIndex in the Open event instead of the Shown event, it always works, and I never get any error.

Bob is right that sometimes you can work around issues by introducing a delay using a WebTimer or some other mechanism. But it’s frustrating to have to do this because it’s not really correct, it’s just side stepping a deeper flaw.

Shown should be valid for the object it is being called on. If you can produce a test project that reproduces this I will certainly sign on and maybe throw some points at it.

Indeed Daniel, I completely agree and the Shown event should be 100% reliable. We should never have this ‘undefined object’ error at this point.

I’m trying to figure out a repro-step that reproduces the issue every time but this appears to be a bit random.

What is interesting is that I have moved some of the commands to the Open event instead if the Shown event, and some of the errors disappeared. This means that Xojo figure out a way to internally ‘delay’ those commands until the control is actually ‘shown’ (or at least available in the DOM) in a more robust way than when presenting the Shown event itself to the user.

This should perhaps gives a hint to the Xojo developers and a direction where to look at to solve this issue.

I suspect that some properties, when set in Open, are sent to the browser as part of a startup script or the initial HTML. When set in Shown they trigger a normal property change script. Some properties in Open will not be packaged as part of the startup package, and may even try to execute the normal scripts, which is why we can’t always use Open to change something.

Ideally we should be able to set properties in Open or Shown and have them properly sent to the client when the control is ready. But there has to be specific code per control to make this happen. It can be tedious to maintain and test.

I deal with similar issues in wcc.

I understand what you say regarding the Open event, yes, you are certainly right here indeed.

Btw, Daniel, or perhaps someone else, have you find a way to dynamically Embed a WebContainer with straight Opacity of 0 ?
(without resorting to a WebAnimator, that is).

In my case, setting a Style with Opacity 0 directly on the WebContainer in the IDE or after having embedded it does not work, Opacity is always 100%.

The issue I have is that I want to smoothly reveal the WebContainer with a WebAnimator and set the Opacity at 100% through it. But at first I have to make it invisible (without setting Visible to False, which is pointless).

Currently I’m solving this issue by using a dummy WebAnimator to set the Opacity to 0 while hiding the WebContainer behind others with the help of ZIndex… But I don’t like it. If I could solve this issue I think some - if not most - of my issues mentioned in my previous messages would disappear.

After depper experiments, it seems things have changed recently.

I recall having Javascript errors when using ExecuteJavascript from the Open Event in RealStudio.

This is not the case anymore, I’ve even tried to use ExecuteJavascript from a WebContainer Constructor, and it works perfectly well.

So there is definitively a cache mechanism that stacks Javacscript calls and trigger them at the ‘right’ time. I’m tempted to say at a ‘better’ time than the Shown Event.

I’ve even moved all my ExecuteJavascript calls from Shown events to Open events. I don’t get any ‘undefined’ error anymore.

My conclusion, at least for the moment, is: avoid the Shown event at all cost and rely on the Open event instead.