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…
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…
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.
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.
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.
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.
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:
no matter what (toFront (true), Process::makeForegroundProcess() etc.) the app window is always behind other Windows and not focused
when “Run as administrator”, the same app is working ok, on the top and focused
the problem disappears too when the JUCE title bar is used (setUsingNativeTitleBar (false))
the only solution I found is to set the title bar to the JUCE-style and after everything is done in the MainWindow constructor, set it again as native.
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?