Bloody Mice!

Please can someone help me - I'm being bugged by mice...

Does anyone know how to prevent the scrolling of the mouse wheel from moving to the next record (or creating a new record) on a form?

Any help gratefully received....

Cheers

Buddy L

Superglue!

Tried it, but I stuck my finger to the mouse...

microsoft kb

http://support.microsoft.com/default.aspx?scid=kb;en-us;308636
for 97

http://support.microsoft.com/default.aspx?scid=kb;en-us;278379
for 2000

I have not tried it - it looks involved

sam

I have read that the examples posted by MS don't actually work, I have seen an example on another site that I'll post if you want to try it.

Here's an example db and a dll file which you'll have to add/register in the VBE ->Tools->Reference. You can then turn mouse wheel on or of programmatically. See the sample db in the zip file. I've tried it, and it seems to work great. You must first register the dll file, or yo'll get an error if you open the sample db.

Gerhard

A better mouse trap?

As developers, we have a challenge to prevent our users from advancing to another record if they do not use the navigational controls we want them to use or to prevent them from bypassing our validation procedures too ensure the current record is okay to be saved. The invention of the scrolling mouse wheel has given most developers (not using Access XP) a challenge to control the users ability to bypass most data validation procedures.

My sample will prevent the user from using the following functions if the current record has been modified but was not saved using my custom save button...

• Advance to another record using their scrolling mouse wheel
• Advance to another record using the default or custom navigation buttons
• Use the Page Up or Page Down keys
• Use the Shift-Enter key combination to save the current record
• Use the F9 key (refresh records)
• Use toolbar options relevant to record operations (sort, find, etc.)
• Close the form

The trick in my sample is the value in the tbProperSave text box. My method ensures the user can not leave the current record if it has been modified unless they save or undo the changes to the current record using my custom save or undo buttons. This also allows you to add your own validation steps to ensure the current record is okay to be saved if it passes your validation procedures.

My method does not use ActiveX, .DLL's or a lot of VBA. My method does not disable the users scrolling mouse wheel, it only prevents the scrolling mouse wheel from advancing to another record if the current record has been modified but not saved using my custom save button.

Please post back if you have any comments or suggestions. Thanks!

What about in the movement from form to subform or vise-versa. Doesn't that trigger a save?

Autoeng

Autoeng,

Yes, a subform adds another layer to the problem. My attached sample has another form with a subform and I am able to easily catch a user modifying records in the form or subform (or vise-versa) and then trying to move around the form without saving the modified record.

Post back if this does not cover your concern. Thanks!

More Mouse Wheel Joy

Knowing the overwhelming sentiments of pleasure that this subject evokes, I couldn't resist some further observations:

I love the solution that ghudson has provided. Clean, simple, and effective. Naturally, I tried to adapt this solution to my own form, but was forced to implement some less-than-satisfactory modifications.

Essentially, ghudson's solution requires the form's record to be Dirty in order to trigger the BeforeUpdate validation. Since many of the controls on my form are unbound (or calculated), my problem was how to account for changes to them as well. Once again taking a cue from ghudson's model, my trick was to create a dummy Yes/No field in the underlying table with which to deliberately 'Dirty' the record in the Form_Current event.

This works like a charm for existing records BUT . . . (and this is where I'd be most grateful for any suggestions) . . . provided that the form is also used for Data Entry (new records), a user can't cancel out of the adding a record without having generated a new autonumber (yes, an autonumber field is my PrimaryKey), hence creating a 'blank' record, all due to my deliberate 'Dirty'ing of the new record. This blows up my record validation as well.

The modification I chose for this problem was to set the form's DataEntry mode to True if the user is adding a record, and conditionally suspend the form from becoming 'Dirty' until the user Submits or Cancels their record addition.

If anyone can think of a less intensive workaround, I'd be desperately anxious to hear from you.

Cheers,
John