Mouse Wheel Behavior

[Scott24x7]

I've been trying to figure this issue out for ages (maybe even a couple of years), but I just pegged the cause of the behavior, now I have no idea how (or if) there is a remedy.

I'm using multiple monitors. When my running EXE is in the "Default Monitor" the mouse wheel on grids works fine (to scroll the grid). But when I move the application to a monitor that is not the default, the mouse wheel no longer moves the grid vertical scrolling.

Does anyone know how to fix this?


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Steve Meyerson]

Scott,

You have probably clicked on the grid before attempting to scroll with the wheel. If not, try that.

I use WizMouse (I think it's free, or at least used to be). It allows scrolling without clicking by just moving the cursor over the grid even if it's on another monitor. That assumes you can move the cursor across monitors, which I believe is normal behavior.

Steve

 

[Chris Miller]

In the usual side by side layout the x coordinate on the non-default display is from width to 2*width of the first screen.

That's where this could come from, but then there must be some code that goes wrong with objtoclient or anything like that, not realizing the higher x coordinate is not off the grid and the form.

I can't replicate that.

Chriss

 

[Scott24x7]

Steve,
When in the default monitor, there is no need to click the grid, it simply works if the mouse is over the grid object, when I move it to another monitor, it does not work, whether clicking inside it first or not.
I probably should mention, this isn't just a double monitor situation, there are 4 monitors in a 2 x 2 arrangement (two on top, two on bottom), with bottom right monitor being the "default". But if I switch default to another, it's the same behavior.

Didn't know if someone knew of some kind of windows call that might resolve this. I have been trying to figure out why the mouse worked sometimes and not others for quite a long time, but I have from time-to-time switched the default monitors, and didn't realize it was only working on what the current default is. Proved that today. But now, still no resolution.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Steve Meyerson]

Scott,

Ok, I understand it's more complicated than my suggestions.

Some other things that come to (my) mind (which you've probably considered anyway):
1. If other apps (e.g. Excel) scroll ok in the non-default monitors, it could be something in your code which tells the grid to move to a non-default monitor?
2. Windows display settings.
3. Display settings driver(s) from the monitor manufacturer (brand)
4. Video driver

Steve

 

[Chris Miller]

The default display (no matter which quadrant it is) will always have coordinates (0,0) to (width-1,height-1) and other displays always have higher coordinates in x or y or both. The coordinate system doesn't rearrange with (0,0) in the left top corner of whatever display is the upper left quadrant.

That surely contributes to that behavior, and if other applications ( a browser, for example) work well with mouse scroll wheel, then VFP surely plays a role and has a bug.
You could try set all forms ScaleMode to 3 (pixels), especially also the _Screen's. But I'd bet the spook only disappears once the 0,0 coordinate is in the upper left display and overall the graphics card multi display configuration distributeds the four quadrants of the 2x2 display so that coordinates become seamless.

Did you always work with the same mouse and drivers all these years? Same graphics card settings? I'd look into multi display settings of the graphics card, that might make the top left display the default and thereby normalize the coordinate system for the desktop to start at top/left 0,0 and go up to 2x display width and 2x display height.

Chriss

 

[Scott24x7]

Thanks Chris,
ScaleMode is set to 3 on all forms.
I'll give this a try as well on one of my dual monitor solutions. I do get the point about the 0,0 I'm just wondering if there is some kind of programming that can help VFP understand "where" the application is, and allow the mouse wheel to work.
I'll keep poking with it, but if there are any other ideas, I'm open!
Cheers.

Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[GriffMG]

That's interesting, but I get a different result.

If I run my exe in the main monitor (on my laptop), I always have to give the grid some kind of focus before the wheel
will scroll it - if I am focussed on a text box, merely moving my mouse over a grid and scrolling has no effect. Once
I have clicked in the grid (or the top left corner of it) the scroll wheel scrolls the grid.

If I move the apps to another monitor I get the same response exactly... this is 100% repeatable.

My forms are modal (type=1) and I don't use read events... perhaps that has something to do with it.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Scott24x7]

Ah, you reminded me Griff, that I have a small bit of code in the MouseEnter event that checks this condition:

LPARAMETERS nButton, nShift, nXCoord, nYCoord
*
IF UPPER(ALLTRIM(WONTOP())) = UPPER(ALLTRIM(ThisForm.Name))
This.SetFocus()
ENDIF

This is in the baseclass code, and I haven't touched that on the GRID object in well over a decade. Only remembered when I saw "Inherited" message in the MouseEnter event.

So it sets focus to the grid just by entering the field. But when I "mouseEnter" when on the non-default monitor, I get nothing for the scroll wheel, nor does clicking it seem to get me anything either. The scroll bars work if clicking in them or the ends, but not the wheel...
Would there be some different result for WONTOP() when on the non-default monitor? This seems quite odd, but maybe related.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Chris Miller]

Do you give all your forms different names?

I wonder why check this at all. The mouse enter event will only occur if the control it happens to is on the form that's on top in that mouse position.

If you only want to set focus to the grid, if the form is the active/focused form to not deactivate the active form just when you hover over something, then you could check whether _screen.activeform is thisform.

But I also think you have a wrong idea of what wontop is. With multiple monitors you surely have multiplle forms that are on top in their display. There still is only one active form on the whole desktop and wontop tells you the name of that form, and only if it's a VFP form that has that active/focused state.

If you want to activate the grid if the grid is visible/in front, then you can simply do This.Setfocus() in grid.mouseenter. Because the mouseenter only happens when this grid is in front.

There's another catch, the mouseenter won't necessarily happen when you move from a pixel outside into a pixel of a textbox in the grid. The grid only is the grid lines, you need mouseenter in headers and any column control. And even then, in the non-active rows of a grid, mouseenter doesn't even happen when you hover over a non-active grid row somewhere not on the grid lines.

To cover the rectangle area of the grid and it's headers, you could add a transparent container and make that your "mouse catcher" and use its mouseenter. That comes with a prize, though, as now clicking on that container needs to forward that click to the point underneath. Not impossible but from the top of my head it would mean to move the container to off form coordinates and repat the click by MOUSE command, then move the container back in front of the grid.

Chriss

 

[Dan Olsson]

I don't know if this helps but on the mouse I use in W10 I can choose if scrolling should be used only in active windows or inactive ones.

 

[Scott24x7]

Chris,
Yes, all forms have unique name, which is why it uses "ThisForm.Name" instead of some other constant.
I've done this to resemble other modern applications. For example, Outlook, if I just mouse over for example the folder area or the message preview area, I don't have to click anything in order to scroll in the area, I don't even have to click on the app to activate it first. I wanted VFP behavior on grids and scrollable areas to work the same way. If I don't put this code in the MouseEnter event, then I must click on the grid, which puts focus on the app, which is not what I want, (I sometimes am looking through data in a VFP app, while updating some other application, like looking up an address but typing that address into another app.

I'll test it, but I suspect if I take all this out, and go back to the "click" the object method, it still won't scroll in the grid, but stand by, I'll confirm it.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Chris Miller]

test it, but I suspect if I take all this out, and go back to the "click" the object method, it still won't scroll in the grid, but stand by, I'll confirm it.

That's not what I said to do. Simply setfocus in mouseenter. And improve detecting mouse enter into the grid rectangle. You still haven't realized that mouseenter for grids is not happening that straight forward as entering a texxxtbox or editboox or pretty much any other control.

Yes, all forms have unique name

Have you checked what's the name property at runtime or do you just asssume it will be the scx file stem name or class name?

The NAME property is NOT automatically set to the class or scx file name. It's "Form1" by default.

If you want to make use of some unique form property that's HWND.

But, alas, you can get most specific if you compare the object references forms are. WONTOP is obsolete, use _SCREEN.Activeform as form reference for it, and THISFORM, as you already use it, for this form. The only catch with _SCREEN.ACTIVEform is, it can be null at times and then read access to that or comparisons will fail or even trigger errors. But it's safe to use in a mouseenter event, as it means there is a form.

And as you don't even care whether the form is the focused form or not, why bother at all about that? The mouseneter happens, so the mouse is over that control and you want to ensure scrolling works, then setfocus, don't make that depend on anything at all, that's the nonsense that can lead to not setting focus and scroll wheel not working.

Chriss