Execution order as an app starts up

This is a question about what happens in what order as an app starts up.

Today I had occasion to try something that’s slated for release in 2020r1. To make it work as I wanted, involved adding an “initialising” flag for a control, that would act as an interlock so that event handlers that kick off as the control initialises can be prevented from doing their stuff until the control’s Open event has completed. The idea was to set this initialising flag to True and then, the control’s Open event would set it to False once it had completed.

If I were instantiating a subclassed control in code, then I could hope to do that initialisation in the Constructor rather than in the Open event handler, but how do I do this with a control I’ve just dragged from the Library and dumped in the window? The Open event for a Control seems to run much too late.

Next I put the setting of this flag (to True) in the app.Open event. But even there, event handlers for the control were running before app.Open had a chance to set the flag.

In the end I just reversed the sense of the flag, since its default value would be False anyway. All then went according to plan.

I sort of feel I’m missing a trick here somewhere in regard to initialising a control.

Controls on layouts are kind of special

I believe there are blog posts about this that I wrote years ago on Xojo’s blog as well as posts I’ve written in their forums
And posts on my own blog since


When you place an instance of your custom control on a layout the code that sets it up is a LOT like

        // this runs the NO PARAM constructor 
       // which is why EVERY control on a layout requires such a no param constructor
       var c as Control = new WHATEVER_KIND_OF_CONTROL       

      // now set all the properties

note that the constructor and any setters for computed properties will be run but OPEN has NOT yet run !

Hmmm. Not sure I see how to get at that. Thanks for the links, BTW.

You cant get at the set up code
My post was simply to illustrate why you might see a sequence that is

   Property setter // esp if you use a computed property exposed in the inspector behaviour
   Property setter