Apologies if I've brought this up before, for some reason the whole
thing has a familiar feeling to me, but looking through archives I
can't find any exact match. I've been tracking down a bug where when
I use scroll (two finger on a mac, but of course the event is
FL_MOUSEWHEEL) and fltk then thinks the scrolled window has focus,
even when the OS disagrees. I'll attach an example program, it should
bring up two windows. The red should make it obvious where fltk
thinks the focus is. If you do some mousewheel scrolling in the
unfocused window, then move the cursor between windows to create some
FL_ENTER events, the red should switch over to the scrolled-in window,
and now, assuming OSX with click-to-focus, the OS and fltk now
disagree about who has focus. I tried this in 1.4.4 but also got
latest dev version from github, and they are the same.
I asked claude about this, and it fingered this bit in Fl.cxx:
```
case FL_MOUSEWHEEL:
fl_xfocus = window; // this should not happen! But maybe it does:
```
indeed, commenting it out fixes the problem. I asked about
consequences, and it thinks the code is making the assumption that
only focused windows can receive mousewheel events, which is
definitely not true on the mac! It's also talking about
fl_fix_focus() as a way to reconcile with the OS, but apparently that
is not called in mousewheel code path. But of course it would be
better to not get the state wrong in the first place, than to
reconcile! But perhaps on Windows or X11 it is true that you cannot
get a mousewheel on a non-focused window? At least the "this should
not happen" comment seems to indicate whoever wrote it wasn't thinking
about OSX, or at least thought that mousewheel only goes to focused
window.
Anyway I'm sure others can ask AI just as well as I can, so I'll stop
there :) One thing I'm suspicious of is that this seems like a pretty
obvious bug and has presumably been in there for a long time, surely
someone would have come across it before, or it's actually intended in
some way, or everyone else uses fltk in a way that naturally mitigates
the problem. I've had a lingering focus bug for maybe a decade by now
which I never tracked down, maybe this was it! I'll comment out the
line in my local install and see how it goes.
// example.cc
#include <iostream>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
#include <FL/Fl.H>
static void
show_widget(Fl_Widget *w)
{
if (w == nullptr) {
std::cout << "<null>\n";
} else {
std::cout << w->label() << '\n';
}
}
class Bug : public Fl_Window {
public:
Bug(int x, int y, int w, int h) : Fl_Window(x, y, w, h), box(0, 0, w, h)
{
box.box(FL_FLAT_BOX);
box.color(FL_WHITE);
}
Fl_Box box;
protected:
int handle(int evt) {
if (Fl::focus() == this) {
if (box.color() != FL_RED) {
box.color(FL_RED);
redraw();
}
} else if (box.color() != FL_WHITE) {
box.color(FL_WHITE);
redraw();
}
if (evt == FL_MOUSEWHEEL) {
std::cout << label() << ": WHEEL";
} else if (evt == FL_ENTER) {
std::cout << label() << ": ENTER";
} else if (evt == FL_LEAVE) {
std::cout << label() << ": LEAVE";
} else if (evt == FL_FOCUS) {
std::cout << label() << ": FOCUS";
} else if (evt == FL_UNFOCUS) {
std::cout << label() << ": UNFOCUS";
}
if (evt != FL_MOVE) {
std::cout << " focused: ";
show_widget(Fl::focus());
};
return Fl_Window::handle(evt);
}
};
int main()
{
Bug win1(200, 200, 200, 200);
win1.label("b1");
win1.show();
Bug win2(400, 200, 200, 200);
win2.label("b2");
win2.show();
Fl::run();
return 0;
}
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkcoredev/CACbaDy414uDO4igT1%3D5w9p8pj4YdK9KYe6dHz-qGaNQfFoLZGg%40mail.gmail.com.
Comments are owned by the poster. All other content is copyright 1998-2026 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.