FL_DRAG stops being triggered whenever a keyboard key is down

36 views
Skip to first unread message

Camille B.

unread,
Jul 28, 2016, 11:08:31 AM7/28/16
to fltk.general
It doesn't matter if I return 1 or not on FL_FOCUS,FL_UNFOCUS and FL_PUSH.
I would like to be able to have different behaviours on the same widget when I move the mouse while holding the left button,
so I tried to use keyboard (in this case shift) to differenciate the behaviours.
But it didn't work, and upon investigation I just realised that FL_DRAG stops being triggered if I press a key.
It doesn't trigger again if I stop to use the keyboard. It does if I release and push the mouse button again.

Thank you for your support!

Camille B.

unread,
Jul 28, 2016, 11:49:50 AM7/28/16
to fltk.general
Ok I investigated further by trying to replicate this in a blank project, and it seems I wasn't totally right.
The FL_DRAG event is actually still triggered. It's just that Fl::event_button() stops returning FL_LEFT_MOUSE when a keyboard key is pressed.
Now at least I can make an easy workaround.

Still, here is the code I made to replicate it :

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
class Test : public Fl_Window {
public:
Test(int X, int Y, int W, int H, const char*L=0) : Fl_Window(X,Y,W,H,L) {}
int handle(int e) {
switch (e) {
case FL_FOCUS:
case FL_UNFOCUS:
printf("In FL_FOCUS or FL_UNFOCUS %i\n", countFocus++);
return 1;
case FL_PUSH:
take_focus();
printf("In FL_PUSH %i\n", countPush++);
return 1;
case FL_DRAG:
printf("In FL_DRAG %i\n", countDrag++);
if (Fl::event_button() == FL_LEFT_MOUSE) {
printf("In FL_DRAG with left button %i\n", countDragWithLeft++);
}
return 1;
}
return Fl_Window::handle(e);
}
int countFocus;
int countPush;
int countDrag;
int countDragWithLeft;
};
int main()
{
Test win(0, 0, 640, 480, "FLTK test");
win.end();
win.show();
    return Fl::run();
}

Greg Ercolano

unread,
Jul 28, 2016, 3:03:23 PM7/28/16
to fltkg...@googlegroups.com
On 07/28/16 08:37, Camille B. wrote:
> The FL_DRAG event is actually still triggered. It's just that
> Fl::event_button() stops returning FL_LEFT_MOUSE when a keyboard key is pressed.

AFAIK, Fl::event_button() is only valid for button events, not other events
(like mouse motion). I think the fact it works at all for FL_DRAG is undefined.

From the docs:

static int Fl::event_button()

Gets which particular mouse button caused the current event.

This returns garbage if the most recent event was not a
FL_PUSH or FL_RELEASE event.

..emphasis on that last bit. Fl::event_button() will have valid info
only for button events like FL_PUSH/RELEASE, not FL_DRAG.

On FL_PUSH, save the state of Fl::event_button() in a class variable
so you can use it later during FL_DRAG, and clear it on FL_RELEASE
for that same button.


Greg Ercolano

unread,
Jul 28, 2016, 3:11:23 PM7/28/16
to fltkg...@googlegroups.com
On 07/28/16 12:03, Greg Ercolano wrote:
> On FL_PUSH, save the state of Fl::event_button() in a class variable
> so you can use it later during FL_DRAG, and clear it on FL_RELEASE
> for that same button.

Additionally, FLTK does keep state bits for all the buttons held down;
the name of that function is different (plural): Fl::event_buttons()
which you can mask with e.g. FL_LEFT_MOUSE. See:

Fl::event_buttons()
http://www.fltk.org/doc-1.3/group__fl__events.html#gaee06c25589974fafb1c8df8d0e2c7c80

That should have state information for the held buttons at all times,
if I'm reading the docs correctly.

Also, there's Fl::event_button1(), Fl::event_button2(), etc.
which do the same, the masks included, letting you check for buttons
being held directly.

Fl::event_button1()
http://www.fltk.org/doc-1.3/group__fl__events.html#ga6ec5fa15a7ea5229cbff8dd507130d46

Fl::event_button2()
http://www.fltk.org/doc-1.3/group__fl__events.html#gad85ae7c11308de6e4653a860729dec77

..etc.


Camille B.

unread,
Jul 28, 2016, 6:19:00 PM7/28/16
to fltk.general
Thank you!
It makes sense now that you made the emphasis on the doc.
I already made a workaround by storing the result of Fl::event_button() in a class member, but it seems Fl::event_button1() will be a better solution.
Reply all
Reply to author
Forward
0 new messages