I’m having hard time searching through Feedback about this. So I’m posting the question here:
Exemple of this kind of error:
Source: Xojo.controls['A64ANFGg'].object().style.zIndex = '100';
In the Shown event of this control I just have:
Me.ZIndex = 100
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.
@ 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.
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.