forums.silverfrost.com

[JohnCampbell]

Paul,

Following the discusion of zoom, I was looking into using the mouse wheel to control zoom. I again tested the option of using mouse wheel support as a returned event when in %gr. I have the following

[JohnCampbell]

Paul,

Correction, I have got this to work, although it is a bit clumsy and delayed. To get the wheel response, I have added a call
i = winio@ ('%mg&', wm_mousewheel, on_mousewheel)
where wm_mousewheel = Z'020A'

This provides support for the mouse wheel interupt via a different callback. Can the same callback service all mouse interupts ?
Could "full_mouse_input" automatically service these interupts also ?
I recall there was a problem using the mousewheel and full_mouse_input together. Am I wrong recalling this ?
I am using the wheel interrupt to do a +10% or -10% zoom from where the mouse is located. "full_mouse_input" is required to provide the mouse position without clicking.
The response timing is a bit clumsy at the moment, as I do a complete redraw on each wheel interupt received.
Not all turns of the wheel appear to work, although there is a delay in the redraw response, so this may be the apparent reason. Any suggestions on how to improve the response, or how to clean out the backlog of wheel turns or is it simply getting use to the delay.

John

[Wilfried Linder]

I use a function to set the zoom factor with the central mouse wheel:

[PaulLaidler]

John

I think that adding a mouse wheel event for %gr was one of those things that I planned to do in some spare moment. I don't recall any problems with this.

You can use the same callback (say for %mg and %gr) but you will probably need the equivalent of a "callback reason".

If I do add the mouse wheel event to %gr[full_mouse_input] then it probably will have the same effect as your use of %mg.

[JohnCampbell]

Paul,

Thank you for the reply. I've been away.
I do now have the program working, using 2 different interrupt handling routines so the functionality as-is is ok. I will try the same interupt handling routine and see if that also works.

I am having some problems with the useability of the mouse wheel, as the response time is very slow, probably as I request a full redraw on each interrupt.
I will try an alternative to speed up the update, where I save the screen to a virtual window and then redraw with a copy, applying the shrink and zoom, then select a redraw when I have the desired view.

To confirm a problem I thought I remembered; Does "%gr[full_mouse_input]" conflict with the mouse wheel response ?

It is preferable to have full mouse input to know where the mouse is when zooming in on the present mouse location, rather than the last clicked location.

John

[PaulLaidler]

I am willing to have a go at adding this functionality to ClearWin+.

Can someone write me a short program that contains a graphics area that might sensibly respond to a mouse wheel input. I know I ought to be able to do this but all of these things take valuable time.

[PaulLaidler]

For the next release I have added mouse wheel information that is available with %gr[full_mouse_input]. The callback will take the following form...

[acw]

Paul - you might already have dealt with this issue but in case you haven't a word of warning: in Win7 (maybe others) using the latest MS intellimouse drivers some mice return finer grain rotations so the wparam hiword is not an integral multiple of 120 (I'm getting quarter turns with a rotation value of 30). If you just divide the rotation by 120 and take the int result you find that some rotations don't have any effect unless you move the wheel by a large amount. I divide the wparam by 120 taking the real result and use that number to allow partial scrolling.

[PaulLaidler]

Thanks. I will adjust the code accordingly.