How To Use Mousewheel?

[dori...@gmail.com]

I have a working project where a slider changes the opacity of some of the objects in the scene. This is working fine. Now I'd like to do the same thing with the mouse wheel. Can't figure out how to do it from looking at the documentation and examples. Would this require that a 'handle' function be written?  I see there's a function called Fl::event_dy which returns mouse wheel activity. I'm guessing that this has to be called within the 'handle' function? I do all my FLTK from FLUID.  My GUI and graphics all take place in a FLTK Double_Window.  I'd like the mouse wheel to drive the slider (which will drive the graphics).  Any hints?  Any examples that show how to do this from within FLUID? I want the mouse wheel to be active whenever the mouse is in the main window. I don't want the user to have to push the mouse, just turn it.

Thanks.

[Greg Ercolano]

On 03/24/15 10:17, dori...@gmail.com wrote:
> I see there's a function called Fl::event_dy which returns mouse wheel activity.
> I'm guessing that this has to be called within the 'handle' function?

Yes, look for the FL_MOUSEWHEEL event, and then you can read
Fl::event_dy() for the position.

I know Fl_Scrollbar uses this; see src/Fl_Scrollbar.cxx and search
for FL_MOUSEWHEEL to see example use.

Let us know if you can't get it to work.

[Ian MacArthur]

Yes, and though it sounds odd to say it, I really think this would be easier to do “in code” than to do in fluid...

Basically, your best bet is derive your own outer window class, derived from Fl_Double_Window, than add a handle method to that to catch the mouse wheel events (all other events you need to just pass on to the base class handle in the usual way.)

You can then use the mouse wheel events to update your slider widget, and hence do whatever callback operations need to be done there...

Well, something like that, anyway.

For examples of deriving your own window class, take a look at the examples in the /test and /examples folders, and of course at Greg’s cheat pages
http://seriss.com/people/erco/fltk/

[Albrecht Schlosser]

On 24.03.2015 22:57 Ian MacArthur wrote:
> On Tue Mar 24 2015 18:30:56, Greg Ercolano wrote:
>>
>> On 03/24/15 10:17, dori...@gmail.com wrote:
>>> I see there's a function called Fl::event_dy which returns mouse wheel activity.
>>> I'm guessing that this has to be called within the 'handle' function?
>>
>> Yes, look for the FL_MOUSEWHEEL event, and then you can read
>> Fl::event_dy() for the position.
>>
>> I know Fl_Scrollbar uses this; see src/Fl_Scrollbar.cxx and search
>> for FL_MOUSEWHEEL to see example use.
>>
>> Let us know if you can't get it to work.
>
>
> Yes, and though it sounds odd to say it, I really think this would be easier to do “in code” than to do in fluid...
>
> Basically, your best bet is derive your own outer window class, derived from Fl_Double_Window, than add a handle method to that to catch the mouse wheel events (all other events you need to just pass on to the base class handle in the usual way.)
>
> You can then use the mouse wheel events to update your slider widget, and hence do whatever callback operations need to be done there...
>
> Well, something like that, anyway.

You may also try to use Fl::add_handler() to get the mousewheel event if
no other widget uses it (which is probably the case). This should work
the same way as in a derived class, but doesn't need to derive a class.

http://www.fltk.org/doc-1.3/events.html

<http://www.fltk.org/doc-1.3/group__fl__events.html#gae2d39bda7362e444afa41166c478b904>

See attached file add_handler.cxx for a working demo. Example output:

[25] Event = 19 = FL_MOUSEWHEEL, (dx,dy) = (0,1)
[26] Event = 19 = FL_MOUSEWHEEL, (dx,dy) = (0,1)
[27] Event = 19 = FL_MOUSEWHEEL, (dx,dy) = (0,-1)
[28] Event = 19 = FL_MOUSEWHEEL, (dx,dy) = (0,-1)

Note: this is a modified version of hello.cxx with FLTK copyright.
Feel free to use my additions for whatever you like.

[MacArthur, Ian (Selex ES, UK)]

> You may also try to use Fl::add_handler() to get the mousewheel event if
> no other widget uses it (which is probably the case). This should work
> the same way as in a derived class, but doesn't need to derive a class.

Oh yes! I'd forgotten that; that's a good idea, much better than mine.

This has the advantage that if some widget does use the wheel, and has the focus, it will still work normally, but otherwise the "system" will catch the wheel events and deal with them.



Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Albrecht Schlosser]

On 25.03.2015 14:17 MacArthur, Ian (Selex ES, UK) wrote:
>
>> You may also try to use Fl::add_handler() to get the mousewheel event if
>> no other widget uses it (which is probably the case). This should work
>> the same way as in a derived class, but doesn't need to derive a class.
>
> Oh yes! I'd forgotten that; that's a good idea, much better than mine.
>
> This has the advantage that if some widget does use the wheel, and has the focus, it will still work normally, but otherwise the "system" will catch the wheel events and deal with them.

This would be the same with the Derived_Window::handle() method,
wouldn't it? So this is not an advantage of the global method. The main
advantage for me seems to be that you don't need to derive your own
window class.

But there is also a drawback that should be mentioned: The
Derived_Window::handle() method would only deliver events related to
that particular window, i.e. only if that window has the focus. The
global handler receives events no matter which window has the focus.
This can be confusing if you have more than one window active (shown),
but the window that doesn't have the focus reacts on FL_MOUSEWHEEL
events. An app developer should probably test if the focus is in the
correct window to make sure this works as intended.

OTOH, it can also be intended that the mousewheel event is used by a
window that doesn't have the focus. I'd say, it depends...

[dori...@gmail.com]

Thanks for the replies. Taking all of your suggestions and looking at code examples, I've patched something together that works, though it seems clumsy. 'Handle' functions don't make much sense to me. I'm not surprised about the comment that this would be easier to do in code than in Fluid. However, I used Fluid to derive a class called 'Wheel_Group' from the standard fltk 'Group'. The clumsy part is that I'm passing the wheel value (-1,0, or +1) back to my main program via a global variable and then back to a fltk slider. What I was hoping to do (which would be much cleaner) was to send the value of the mouse wheel from the callback of my 'Wheel_Group' widget directly to the slider widget. So I have a follow-up syntax question. Say I have a widget called 'Dori', which is one of my 'Wheel_Group' widgets. In the Fluid callback code section of Dori, what would the syntax be to retrieve the value returned from the handle function (i.e. the value returned for Fl::event_dy())?   Thanks.