Block mouse behavior in an external ActiveX control

Question

In the access-related access form (2002/2003), the rotation of the mouse wheel moves to the next / previous record, even if the cursor is inside a multi-line text field or list. This is a serious annoyance for users and cannot be easily turned off.

I recently discovered a DLL called MouseHook ( http://www.lebans.com/mousewheelonoff.htm ) that can effectively block this mouse behavior and replace it with a more expected behavior.

However, when an external ActiveX component is added to the Access form, this module does nothing. For example, I have a form with a FlexGrid control, and it can contain many rows. When a user tries to scroll there using the mouse wheel, Access simply goes back to another entry, even if the MouseHook DLL is loaded.

Is there a solution like MouseHook DLL, but which also works for external ActiveX controls? Or is the source code for the MouseHook DLL available, so it can be modified to control elements like FlexGrid?

PS: I wanted to ask the author of the MouseHook DLL, but he is currently on hold until June 2009.

Answer 1

If you really need to change the user interface and change the way you use the mouse wheel, I would recommend just turning it off, rather than changing the way it scrolls. Although scrolling might seem strange to you, this is how the program works. What would you do if you had to read the PDF all day, and then one day one person decided that the way to scroll the mouse wheel was not good enough and was changed so that by default it didn’t perform large jumps or horizontal or something else . Yes, this could be a better solution, however it annoys the user because he does not do what he should do.

Answer 2

Why are you using flexgrid in Access? For me, this is a reading flag, which you probably approach the project in terms of Access hostility, since you seem to choose non-native controls to do things that are almost always much easier to do with your own Access controls.

Answer 3

Grab the flexgrid, intercept the WM_MOUSEWHEEL message, ignore it and call your intended behavior.

Answer 4

Not a direct answer to your question, but the way we deal with the movement of the mouse wheel is to prevent accidental changes to the records after the user has started editing. When the user opens the form, the wheel moves the records perforce, as usual. As soon as the user edits something on the field and then moves the mouse wheel, the BeforeUpdate event is triggered, which leads to the fact that our code displays a hint that you need to save the record first. We have a save button that the user must explicitly click to suppress the warning in the BeforeUpdate event.