First a bit of history We had a problem with running code when a window was opened. At first we put the code in internalFrameOpened, but this event only fires once when the window is first loaded - if the window is loaded from the cache this event doesn’t fire. (Disabling caching is not an option due to the number of users and slow speed of parts of the network.)
We then used the internalFrameActivated event. This worked but had an additional problem - if you click on another window (such as a docked header) and then back on the first window, the event fires again. We got round this by opening the window with a custom property called runOnce set to 1. The code in internalFrameActivated was set to only run if runOnce was set to 1. The last thing this code did was set runOnce to 0, so it would not run again until the window was closed and reopened.
This worked but always felt a bit messy, so we were pleased to hear about the new visionWindowOpened event in this post. It looked like this would solve the problem, but it seems to have a serious issue.
With both internalFrameOpened and internalFrameActivated, if you run an invokeLater command (to change something on-screen using the result of a binding for example), the invokeLater runs after the bindings are read (it must be being put on the stack after the request to read the bindings). With visionWindowOpened however, the invokeLater runs before the bindings are read. (It is actually possible to get it to work by nesting 2 invokeLater calls, but this doesn’t seem very practical!)
Is this intentional? It would seem sensible that using invokeLater with visionWindowOpened should work as ‘normal’ i.e. after any bindings have been read.
I have attached a demo window to show this in operation.
visionWindowOpened.proj (7.07 KB)