App or Program Flow


Is there a way to map how an app flows? What I mean is what order events are triggered ? I don’t know if this makes sense but the reason for asking is that I am debugging my app using breakpoints which is very useful then stepping on to the next as usual. A for instance is when a window is open what is the trigger order of the control events, is it alphabetical Control name then alphabetically event sequentially? BUt then something being set in an early event may trigger an event else where in the window therefore raising a possibility of that event being triggered twice. This is fine when I have something which is clearly not right, but my app is doing something odd…it works sometimes then not the next and I am trying to track down what is happening i.e. something is causing an event to be triggered unexpectedly or a constant is not set so find when this that or the are set is proving cumbersome etc…

Doing this with breakpoints is hugely time consuming. Whereas being able to see the order of events triggered I believe would help me enormously. Perhaps I do not use the debugger properly and this is in no way meant to be a criticism of the debugger. This is proving more difficult to articulate than I had imagined

ANy advice?

Interacting with the debugger can affect the order of events being called (such as Active/DeActivate/Paint, etc.).

You might instead try using System.DebugLog and then checking the Messages panel at the bottom after (or while) your apps runs.

You cannot rely on any specific event handler order, although you can rely on general things like your control’s Open event handlers are called before the Window’s Open event handler.

one of the mistakes a lot of people make that disrupts event order is to refer to a property of a window before that window would normally be opened (especailly if it is the main window).

If you have “implicit instance” on (which is the default)… and you do something like "window1.title=“xyz”’ then window1 will have to instantiated right then, instead of “waiting” until the normal event flow would have opened it.

Not saying that is your specific issue, but it gives you an idea of what kind of things might be involved.

Many thanks Dave and Paul…very interesting.

I will have a go at using the system.debuglog when I can work out how. I have to admit I would have thought that a window open event would have been the first event - which is obviously not correct.

I think the problem is along the lines you have described Dave, I am reading lots of info from a database and populating various listboxes, comboboxes around the app so I would not have to keep opening and close the DB (as I am using 4 others elsewhere) so I guess use of global arrays in a module is the way to go. I tried the implicit instance off but got in so much of a muddle it is one one the control I do not touch anymore.

THanks again…food for thought

You might want to move any code the populates a listbox (or similar controls) to their OPEN event… that way you know for sure

a) they get populated before they display
b) they get populated after the window hosting them has properly initialized
c) they don’t disrupt the normal flow of events

@Dave S - Great advice…I’m on it!!!

It amazes me how things as obvious and simple (when it’s pointed out) as this can really screw you up before you know…hey ho!

Any code that initializes more than one control should go in the Window’s Open event, because you know at that point that all the controls exist.

Hi, in line with this, is there a process that runs before app.Open? My Windows 7 remote debugged app is crashing before that point and I have no idea where to set a breakpoint. There are no errors in the project check, either.


Edit: Figured out what the problem was: there were a couple of previous processes that had crashed while debugging that had to be killed. However, it would still be interesting to see if is the first overall method that runs when the application loads.