Re: WIDGET_DRAW event.press/release values for mouse wheel events..undocumented? [message #55383 is a reply to message #55296] |
Thu, 16 August 2007 13:09  |
Paul Van Delst[1]
Messages: 1157 Registered: April 2002
|
Senior Member |
|
|
Richard Clark wrote:
> In version 6.4 I think you need to explicitly enable wheel events to
> have them passed through to your event handler.
>
> In my case the wheel was just a source of noise to be ignored. If you
> will be using the wheel then you may also need to guard against
> accidental button presses on the middle button when you meant the
> wheel:-) But then I think the TYPE tag on the event structure may have
> a distinct value for wheel events too... I was only interested in
> silencing the thing.
That was my initial need too. But now I'm wondering if I can (should? :o) use the wheel to
enable some sort of centred in-and-out zooming of my current data plot (e.g. like in
google maps).
My particular app doesn't (yet) use the middle button, just the Left (click and drag
zoombox) and Right (return to original zoom) ones.
cheers,
paulv
>
> Richard
>
> In article <fa253r$8er$1@news.nems.noaa.gov>,
> Paul van Delst <Paul.vanDelst@noaa.gov> wrote:
>> Richard Clark wrote:
>>> Yes, I have encountered this too. We use intel linux systems with pc
>>> type wheel mice.
>>>
>>> Neither the bu... I mean feature, nor its fix (in version 6.4) seems
>>> to be documented.
>>>
>>> After checking event.type for UP, DOWN, or MOTION mouse events, check
>>> for PRESS or RELEASE values >4.
>>>
>>> Here is a code snippet from a heavily modified version of Fanning's
>>> DRAWBOX_WIDGET example procedure that I use to get around it.
>>> It looks like you've already found the same fix.
>> Similar. I now use the following:
>>
>> FUNCTION WPLOT_Which_Button, Value
>> CASE Value OF
>> 1: e='LEFT'
>> 2: e='MIDDLE'
>> 4: e='RIGHT'
>> 8: e='UP'
>> 16: e='DOWN'
>> ELSE: e='NONE'
>> ENDCASE
>> RETURN, e
>> END
>>
>> and call it thusly:
>>
>> IF ( WPLOT_Which_Button(event.RELEASE) EQ 'LEFT' ) THEN BEGIN
>> ....
>>
>>
>> I decided to use the CASE statement since one can't rely on the 8 and 16 values remaining
>> valid (and apparently, in v6.4, they're not)
>>
>> cheers,
>>
>> paulv
>
>
|
|
|