@BlueHazzard: Your understanding is not quite correct, but the effects of CallAfter() and the timers are technically the same, they move the processing time of the code fragments out of OnInit() into OnRun(). I am a bad teacher but i try to give a short overview of what is happening.
After OnInit() did finish the thread that does execute OnRun() becomes the main thread. This main thread just drives the main event loop which is processing the events. This is done roughly speaking by passing each event through the event handler chain until it is processed. In wxWidgets pretty much every GUI element is an event handler and these form a vertical chain. Most simple case is a button inside a frame:
wxButton -> wxFrame -> wxTheApp
So if the button gets clicked the event loop first calls the event handler of the button, if that doesn't process the event it is passed to the frame and if that also doesn't process it, it is passed to the global app object (this is very simplified, check the wxWidgets docs for details).
In your OnInit() method the CallAfter() and the timers actually queue the event in the App object and nothing more happens there. Only when OnRun() starts executing they will be actually executed. On the other hand in OnInit() your Manager object manually processes the startup event. This itself might be an issue but what is even more problematic is that im pretty sure that your own event handling system uses wxWidgets events and processes them horizontally.
This means in contrast to wxWidgets where event processing ends when the event got consumed you pass the event to all other registered sinks as well. This usually is not a problem unless one of the sinks opens a modal dialog (or anything else that causes the creation of another event loop). Because control flow has to stop for the modal dialog, another event loop gets created which is again driven by the main thread. This ensures that event processing does not stop. In horizontal processing this has however the side effect that after that modal dialog got closed, the originating event that opened it gets passed along to the next event sinks. So this "old" event gets further processed after all the events that it might have created.
I hope this wall of text doesn't confuse you even more but maybe gives you some ideas what can cause the present problems.
@oBFusCATed: I don't think idle events are the way to go, they happen all the time and are not suited for one time tasks. These lambdas are nice to write code in one place and let it execute in another place, like work units for a work queue. But i also like
auto so im afraid we won't agree here as well