Something between AlwaysOnTop and normal windows

Don’t know on the progress, but I have created a work/hack-around to get by.
It was all done in the Win32_Windowing (or similar name).
As Stian says, the flags etc to make the window is not a big deal to implement, but you also have to consider some other Juce “assumptions” regarding parent child relationships (see my post about coordinates).
@Stian jøss, første gang jeg har sett en annen Juce-utvikler fra nabolaget her.

Thanks, Nikolai! I’m usually not keen about maintaining our own JUCE branch, but we’ve done that a couple of times before. I suppose I might have to do so in this case as well… It seems quite essential, though, so we might hope for “an official” solution.
@Nikolai: Artig – hvor i landet er du? Jeg er i Oslo. Du kan sjekke hvis du er interessert. :slight_smile:

Yes this is a basic and commonly used feature of windowing systems, and almost impossible to emulate by other means. This is why UI toolkits usually have a way to specify the parent window of a dialog box. Eg. this is the signature in Qt:

QDialog(QWidget *parent = Q_NULLPTR, Qt::WindowFlags f = Qt::WindowFlags())

To fix finding the window at some given position you could go to the source — the Windows API:

POINT pos;
// in this example we use the cursor position
HWND hWnd = WindowFromPhysicalPoint(pos);
// WindowFromPhysicalPoint can return heavyweight components, this
// gets the top-level window if desired:
hWnd = GetAncestor(hWnd, GA_ROOT);
// I'm guessing at this point HWNDComponentPeer::getOwnerOfWindow(hWnd) will get
// you the JUCE window we're looking for

Note also that the current approach of Desktop::findComponentAt has the obvious flaw that it doesn’t take into account windows from other applications. As a consequence when dragging between windows, you can drop on a window which is hidden behind a window from another application.

Yep, we hear you. It’s a good request, we’ll certainly add it to our backlog.

Has this feature request made it off the backlog in JUCE 5?

Nope, I’m running with a modded/hacked solution that works. Although not elegant

+1. I’m going to have to hack this for the moment. We should be able to create ‘owned popup’ windows (to use MS Windows parlance), so they always stay on top of their parent window. It’s especially awkward when you don’t want them to appear on the Windows task bar (ie. like any normal desktop app with a main window and floating tool windows) - there’s no way to get to them when they go behind the main window. Hoping for a fix (well, implemented FR at least) ASAP please!

1 Like

I’m hoping for this as well… :wink:


+1 just running into this

1 Like

+2 I could really use this as well.

1 Like

Hi, anyone got this working?

I solved this years ago in QT in the following way:

  • add a list that specifies the z-order of child windows to your top level window
  • on each mouseUp event, I restored the z-order by calling toFront (false); in that order (a globalMouseListener would work here)
  • you can add at mouseDown the chance, if you have windows of the same importance to bring the clicked to the front of that part of the list

I remember that worked quite well, I think this approach could be used in a JUCE project as well…

That wouldn’t really have been necessary in Qt, though, because it already has the Qt::Tool window flag…

1 Like

…did it have that 2005? :wink:

Also you can do that with an arbitrary number of windows. The tool is one flag, my approach made it possible to have a base window, a couple of floating ones of the same importance and so on…

+3 – really need it here as well. Our host is just a regular application; on MacOS our modal plugin window gets the “topmost” style so it stays on top of everything else on the desktop, and on Windows it’s all to easy for the dialog to get behind the (now disabled) host app (e.g. after an alt-tab), leaving our users scratching their heads…

I did something similar, the downside is that it still messes with the order of windows when using Alt+Tab. Mainly if one of your “tool” windows is focused then as far as Windows is concerned your main window is not focused and it will be the first window in that list, in effect breaking Alt+Tab.

@CarlColijn That is probably a related problem, JUCE does not fill in the parent window handle field when creating windows, so as far as Windows is concerned there is no hierarchy between those windows. I had to fix that issue with native file choosers.

I’ve hacked together another solution that also seems to work;

Though I first want some confirmation from someone else on whether it is a correct design before I put it into production code.


+1 This would be great to have. Users have complained that one of our popup windows stays on top of the application, but also on top of every other application. I’d like something that stays only on top of my app, but goes behind other apps.


I’m also running into trouble with OSX not showing my window as the top-most one. :-(((( on Windows it was very easy to do. Why OSX has always be so complicated for such simple things? :frowning:

Has this been addressed in Juce 6?
My hack on windows gets messed up by the dpi awareness, so if you drag the panels from one screen and on to the next (with different DPI) it gets messed up.
Before I invest more time in this it would be good to know if a native Juce solution is in the works

1 Like