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!
I’ve got this problem in my app too. I try to use “toFront” in several places - in MyAppApplication in initialize function, in MainWindow class in constructor, and even in MainComponent class with getTopLevelWindow() - and it doesn’t work, so when I start my app it’s only visible in the Windows bar. Of course when I click on the icon in the bar, the app window is showing.
How can I do this?
You might not have your process as foreground process.
Calling the static method Process::makeForegroundProcess() might do the trick.
Where I should call this method? I try to do this in initialize function, and in MainWindow constructor - it doesn’t works.
In normal situations it shouldn’t be necessary at all. I would assume it is because you are starting from the debugger. Try starting like a user would do, i.e. double click from explorer, and I guess it is working as expected (I’ve seen similar behaviour on Mac with an Application, I couldn’t figure out why it happened for that particular app).
I needed the makeForegroundProcess, when I implemented a Video player where I could drop movies from explorer into. Here the OS wouldn’t know, if you want to come to foreground.
I am not starting from debugger - I make the Release x64 app, and when I want to test app, I open it from explorer (I’ve got a shortcut on the Desktop). I try several locations of Process::makeForegroundProcess() and toFront() functions - in each case my app is not showing at the top of another applications.
That’s strange, that works usually. Are you using the standard JUCE application template?
My application is based on MidiDemo.h project. But now I created the new Audio App project, compile it and again - the window is not on the top.
But I noticed something - when I run my app or the app which I’ve just created, the app window is “second from top”, I mean when I open the explorer, and click on the app, the appwindow is created under the explorer window. When I open app from shortcut on Desktop (I’ve got 2 screens), and in main screen I’ve got a Visual Studio, the app window is created under the Visual window.
So the appwindow is not under all windows, just under the latest top window.
Figured it out ! I make a trick with setAlwaysOnTop function:
mainWindow.reset(new MainWindow(getApplicationName()));
mainWindow->setAlwaysOnTop(true);
mainWindow->setWantsKeyboardFocus(true);
// some parts of the code here
mainWindow->setAlwaysOnTop(false);
So first I turned on this function, and after creating the objects I turned it off. This happens if Main.cpp file, and it works exactly that I want 
Similar case to the described above: I’ve just received some reports from testers that my standalone application is launching behind other windows on some pc’s with Windows10. Indeed, I’ve got one machine where this problem can be reproduced:
toFront (true), Process::makeForegroundProcess() etc.) the app window is always behind other Windows and not focusedsetUsingNativeTitleBar (false))I assume something strange happens when creating components and objects in my MainComponent class and therefore the app window is not brought to the front. Why it is related to the native title bar?