Wiki Home

Scrolling With Mouse Wheel


Namespace: Wiki
There seems to be a strange quirk in how VFP handles scrolling of edit boxes with the mouse wheel which is driving my customers crazy. The code sample below shows a simple example of what I mean and also includes some text which describes the problem.

LOCAL oFrm

oFrm= CREATEOBJECT("TestForm")
TEXT TO oFrm.Edit1.Value NOSHOW PRETEXT 1 + 2
	The problem displayed here is to do with
	using the mouse wheel to scroll the edit
	box. When the edit box has focus and the
	edit box is scrolled, any attempt to
	select text with the mouse will work
	as expected. However, when the edit box
	does not have focus and the edit box is
	scrolled, any attempt to select text with
	the mouse will jump the box back to its
	original position. The selection doesn't
	begin where you would expect.
	
	This drives my users crazy. In all their
	other applications (eg MS Outlook) this
	works as expected. However in our VFP
	application it jumps around in a very
	illogical fashion.
ENDTEXT

oFrm.Show(1)

************************************
DEFINE CLASS TestForm AS Form
	ADD OBJECT Text1 AS TextBox WITH ;
		Height= 37, ;
		Left= 36, ;
		TabIndex= 1, ;
		Top= 12, ;
		Width= 289

	ADD OBJECT Edit1 AS EditBox WITH ;
		Height= 109, ;
		Left= 36, ;
		ReadOnly= .t., ;
		TabIndex= 2, ;
		Top= 84, ;
		Width= 289, ;
		Value= ""
ENDDEFINE


Ken Senter suggested modifying the SelStart property of the edit box in the MouseWheel event but there doesn't seem to be nearly enough information passed into the MouseWheel event to make this work cleanly. For example, if I configure my mouse wheel in the mouse control panel to scroll one line at a time I get exactly the same parameters to the MouseWheel event as I do when it is set to scroll three lines at a time.

David Bower suggested adding code that would force the focus onto the edit box when the MouseWheel event fired but that wasn't particularly successful either (and has some horrid side effects in some of our forms!).

I think this is a VFP bug. However I'd love to hear any ideas on how to fix it or work around it. It occurs in VFP 8.0 SP1 (as that is what we use now) but it still happens in VFP 9.0 beta as well.

Thanks! Rob Spencer


Just happened across this 6 years later. Try modifying the class like this:

Define Class TestForm As Form
   Add Object Text1 As TextBox With ;
      Height= 37, ;
      Left= 36, ;
      TabIndex= 1, ;
      Top= 12, ;
      Width= 289

   Add Object Edit1 As EditBox With ;
      Height= 109, ;
      Left= 36, ;
      ReadOnly= .T., ;
      TabIndex= 2, ;
      Top= 84, ;
      Width= 289, ;
      Value= ""

   Procedure Edit1.MouseLeave
   Lparameters nButton, nShift, nXCoord, nYCoord
   This.DblClick
   Return

Enddefine


Works pretty well but, it will fire any code you have in the Dbl-Click event.
Jeff Knapp


Rob: Not that its any help but I've had problems using the MouseWheel with read-only grids in VFP 8 and VFP 8 sp1. I have not verified these behaviors in VFP 9 beta.

Problem 1: The first time the mouse wheel is used within a grid a cell may get focus. Happens about 1 out of 10 times.

Problem 2: After a mouse scroll event in a readonly grid, the grid's drag and drop events stop firing. The solution is to open a form and then close it. The process of opening another form does something to reset the environment messed up by the mouse scroll event.

Conclusion: The VFP mouse wheel scroll event has some bugs.


This is worse than simply getting focus. Add a grid to a form and add a checkbox column on it (sparse = .f.) . Set the focus into the checkbox column. Check the checkbox. Now scroll the wheel. The checkbox checks and unchecks and the grid doesn't scroll.

Now move outside of the column and scroll down with the scrollwheel - it works BUT if you move your mouse back into the checkbox column ,it will check or uncheck the option without you even clicking the checkbox.

Conclusion: Definitely has some bugs. Need to get these reported for SP2.

On losing focus an editbox scrolls back to the point you left the cursor if that point is no longer visible. Weird.

As for the selection problem, try this :

	PROCEDURE edit1.MouseWheel
		LPARAMETERS nDirection, nShift, nXCoord, nYCoord
		* Set focus to this control
		If Type("thisform.ActiveControl") # "O" or thisform.ActiveControl <> this
			this.SetFocus
		EndIf
	ENDPROC


-- Rhodri C Evans


I'm using Visual Foxpro 8.0 SP1 and am also having the problem with a checkbox and scrolling the mouse. When you place the cursor over a checkbox that has focus, every time you scroll the wheel the checkbox will check or uncheck itself. This actually triggers the checkbox's Click event. Here's my dirty workaround:

There are two "normal" ways my users change the value of checkboxes. They either (1) left-click them with the mouse, or (2) press the spacebar or enter button when the checkbox has focus. In the first case, a MouseDown event is always triggered before the Click event. In the second case, a Key Press event is triggered before the Click event. Using the scroll wheel only triggers the Click event.

Start by turning on the checkbox's ReadOnly property. Place the following code in the MouseDown event:

	IF nButton = 1 && Left Click
		this.ReadOnly = .F.
	ENDIF


And this code in Key Press:
	IF nKeyCode = 32; && Space
		or nKeyCode = 13 && Enter
		this.ReadOnly = .F.
	ENDIF


Finally, in the Click event place:

	this.ReadOnly = .T.


The result is that when the user legitimately wants to check or uncheck the checkbox, it will become editable just long enough to change values. But when the user wheels over the checkbox it won't change values because it's ReadOnly. It's ugly, but it works.

-- JP


Category Questions
Category VFP Bugs
( Topic last updated: 2014.03.07 03:33:12 PM )