I feel that I have done this before but I can’t figure it out after quite some searching.
Simple enough - I have a DocumentWindow. I create it at startup, when I get a message I populate it and make it visible.
This all works fine - but I want the DocumentWindow to pop up in front of all other windows, and it seems to prefer being at the back.
I am definitely calling toFront and I’m baffled as to what I’m doing wrong…
Usually that happens if you call toFront before the OS has actually had a chance to physically show the window on the screen. To be sure, you might need to use an event to asynchronously send it to the front shortly after construction.
Aha, logical enough. I’ll try that, I’ll bet it’ll work.
This explains also why it worked in my other program and not here. I can see that I pop up the window and then immediately toFront it.
As usual, I’ll suggest putting this into the documentation so you can avoid answering the question again in future. I don’t think Component::toFront is quite the right place to do it, though - this only applies to DocumentWindows - perhaps as a general comment at the start of DocumentWindow?
Are there other calls that have this property? You could also document those calls in the same place.
I spoke too soon - that doesn’t seem to do it. (Mac OS/X, 10.6.8.)
You can see the actual code I’m working on here. Note that I’ve instrumented toFront and even put a sizable delay before calling the actual toFront (and yes, it’s this one that’s being called).
I set a breakpoint at that point and stepped through Component::toFront - even into the Objective-C (which I’m not so familiar with but can piece together). Everything looks fine - no problems - except that the component does not, in fact, move to the top…
I’m now going to try a clean build, and then a clean release build (this was built using debug) but I don’t hold much hope for that strategy.
My best guess is that it has to do with the somewhat unusual flow of control.
This program is a client of a master Python program which talks to it through a socket. When the program starts up, it creates the window but doesn’t make it visible or populate it. “Very soon” (in a few milliseconds) the socket connection is established, and the master then sends the client the configuration information it needs to populate itself.
This all works perfectly well - if I bring the window to the front it’s populated and flashing away happily. It just doesn’t make it to the front.
What I think I’m going to try is to not even create the window in the first place until I get that first configuration message. That’s a tiny bit tricky to implement (for boring reasons due to the code) but shouldn’t be too much work. If that DOES work then I’ll direct you to the commit that shows the differences - if it DOES NOT work I’ll come back here and whine again. 
Oh, I can also try this on the Raspberry Pi and see if I get the same results, and in fact I will. The RP takes a looooong while to compile C++, but I need a snack anyway…
One random thought: if you have multiple processes, and another one process comes to the foreground after your GUI has started up, it could be that the OS prevents your code from stealing the focus?
Do you mean thread starvation?
Hmm, that might be an interesting possibility - I send updates from the master fairly rapidly…
EDIT: as evidence for this, in experimentation I believe I saw the application pop to the front very quickly as I shut down…
No - I meant that the OS sometimes deliberately disallows an app from becoming the front process, to prevent annoying apps popping themselves to the top when you’re busy using another one.
Gah, really?! 
That might well be it. And that’s really sucky, because I do in fact want exactly that behaviour. The user is in front of the “master application” - a console application, yes, people still write those - and when they start up the client, well, they want to see the client on top (I have a bug report on that from a client).
I’m going to experiment with this idea. If that’s it, I’ll report back, and I suppose I’ll add it to my FAQ and my tutorial…
That seems to be it.
It works fine on the Raspberry Pi, even if I almost kill the client with so many updates that it can’t even refresh its screen, but it doesn’t work on the Mac even if I slow down my frame rate to nothing.
It’s in my FAQ now at least!