focus to subwindows

[holm.h...@gmail.com]

Hello,

I open several subwindows in my program:
win1 = Fl_Window(..);
win2 = Fl_Window(..);

later in my program I can show first win1, then show win2.
win2 will then show/over win1.

However win1 can still catch mouse-events - even if it is below another window.

I guess I have done something wrong here. Any hints ?

Best regards
Håvard

[Albrecht Schlosser]

On 11/14/25 16:09 holm.h...@... wrote:
> I open several subwindows in my program:
> win1 = Fl_Window(..);
> win2 = Fl_Window(..);

You should really be more precise with the code you post to request help.

> later in my program I can show first win1, then show win2.
> win2 will then show/over win1.
>
> However win1 can still catch mouse-events - even if it is below
> another window.

How does it "catch mouse-events" ?

> I guess I have done something wrong here. Any hints ?

Well, I must guess too. If you want to open two distinct windows you
must call end() on the first window before you create the 2nd window.
Otherwise the 2nd window will become a subwindow of the first window -
which seems to be the case in your program.

If this doesn't help, please post more code, ideally a small but full
(i.e. compileable) program so we can test and find the cause.

[Albrecht Schlosser]

Addition: maybe I missed that you wrote that you *want* subwindows, but
I must still guess that you didn't (but used the wrong term regarding
FLTK window types. But anyway, we may need more info...

[Matthias Melcher]

Assuming win1 and win2 are both independent windows on the desktop (sbwindows in FLTK have a different meaning), the yes, all windows of an app receive mouse FL_ENTER and FL_LEAVE events, and if your event handler replies with '1', they will receive FL_MOVE and FL_PUSH events as well. That is intentional because most desktops allow for "click through", meaning, you can click on a back window, and it will not only be raised to the front, but it will also receive FL_PUSH and the following FL_DRAG events.

You can switch off any event delivery to other windows of the same app, either by making a window "modal" with win->set_modal(). This makes the window behave like a message dialog, and no window will receive events until the dialog is closed. Or you use Fl::grab(Fl_Window*) to grab all mouse and keyboard related events and send them to this one window only. This works well, but is usually quite unexpected for the user. Don;t forget to release the event grabber by calling Fl::grab(nullptr).

[Ian MacArthur]

On Monday, 17 November 2025 at 10:27:26 UTC Matthias Melcher wrote:

You can switch off any event delivery to other windows of the same app, either by making a window "modal" with win->set_modal(). This makes the window behave like a message dialog, and no window will receive events until the dialog is closed.

Tradition dictates that, at or around this point, I have to pitch in and point out that window modality is tri-state, not binary:

So a window can be:

Normal - which is just a normal sort of window, and can be above or below any other window, depending on which window has focus. The window with focus gets the events.

set-modal - which is always on top of its "parent" window, and will always capture events to itself _or_ to its parent (most menu systems have this type)

set-non-modal - which is always on top of its parent, but should not affect event delivery to the window that has the focus (floating toolbox windows typically have this type)

Both set-modal and set-non-modal windows need to have a "parent"; typically this is done by making the desired "parent" window topmost when the modal window (either type) is created and shown for the first time.

You _can_change the modality of a window at runtime, but doing so is a bit involved and can make the windows flicker a bit during the change. The docs explain how to do this.

 

Or you use Fl::grab(Fl_Window*) to grab all mouse and keyboard related events and send them to this one window only. This works well, but is usually quite unexpected for the user. Don;t forget to release the event grabber by calling Fl::grab(nullptr).

Yeah - or just avoid doing explicit grabs in user space code, 'cos in my experience it never goes well!

 

[Matthias Melcher]

Yes! Thanks for emphasizing this!