Disabling Mouse Wheel: MS's Solution question

[Amaranth]

Hiya,

Ok, I did the relevant search, and read the substantial material you all have already posted on the subject. The "better mousetrap" solution, on this site, is a damn good peice of work. The only problem is, I'm just as worried about a user fiddling with a record she shouldn't be on as I am about her not saving the one she's using correctly. This leaves me, basically, relying on the mercy of the Microsquish solutions.

However, I have a question: MS's second solution, which internally modifies how the wheel reacts, contains the warning "If you implement this solution and your users open the Visual Basic Editor, the code in this section will cause Microsoft Access to stop responding."

Ok...so let me get this straight - I use the VB editor to enter the code, then it's there forever? If I try to open up the VBE to code anything, Access will explode in a shower of MS marketing genius (that's crash, for the not-so-cynical)? I can't possibly be understanding this correct, because if I am, no one would ever use this option...would they?

 

[jdjewell]

Only if you try and do it all within Access

VBA associated with an Access form was not designed to do what you want to do. As such, MS provides a workaround to do it all within Access, but at a (potential) cost. It does not say that after you quit and restart that if you go into the VBE that it will lock up at that point, but again even if it did, you are trying to use VBA for that which it was not intended: COM development.

If you have VB 6.0, I would suggest following the other directions on that page (develop .dll, reference .dll, create object and utilize methods/properties/events).

 

[Amaranth]

*chuckle*

All right - I have VB, and the sturdy hope and prayer that snip coding the .dll won't end up in a very long day of re-installing Windows. The problem I face, however, is the fear that it would remove all functionality from the wheel while looking at a form. I do have forms that are in list format, allowing the user to scroll down a list. If that breaks...well, have you ever seen a user who had their mouse wheel removed after getting used to that functionality? I'd invite you all to my last BBQ - the one where they burn me at the stake.

I suppose this is a case of wanting to have my cake and eat it too, though. Maybe I should just brow-beat the boss into buying AccessXP, which I've heard has this functionality internally.

Ah well...Thanks, though.

 

[jdjewell]

Access XP

If you want, I can check on that for you when I get home tonight. I have Access XP at home, but not at work. I can check and see if it has the functionality you desire and let you know.

 

[Amaranth]

Would certainly be appreciated.

Thanks again,

 

[ghudson]

Amaranth,

Thanks for the compliment, I am the author of A better mouse trap?

The only problem is, I'm just as worried about a user fiddling with a record she shouldn't be on.

Can you clarify on what you want to prevent the mouse from doing?

Also, I have read posts that state Access XP has mouse wheel events you can code for.

 

[Amaranth]

Heya

Basically, my concern lies with users not necessarily saving things not meant to be saved, as I'm a newbie coder and my anti-idiot code is relatively harsh, i.e. If this field, the only liked field to the primary table, is blank, then on close delete query is going to take care of it. My real problem is making sure users don't end up editing records already in the system, or for the most part, even look at them without going through proper channels. I have "me![Field1] = forms![form]![Field1]" in a couple of places that I worry about going off and trashing my sub-tables. A similar concern is, of course, the user hitting the thing and ending up on another record, and editing it without realizing it.

Y'know, I'm beginning to realize it's almost as hard to explain what the heck you're coding as it is to do it Regardless, I have three main forms - DataEntry, DataSearch (which uses a subform records selector filter), and a form for my sub-table that has all of the history for the base record.

This make any sense what-so-ever?

In any case, on the bright side, I figured out the MS resolution (yay for step-by-step instructions), and it seems to do everything I want. I was mainly worried about it disabling wheel functionality in all Access DB's, but had I actually read it instead of crying like a baby at all the mean looking code, I would have noticed that each form requires a private sub with a reference to the .dll. Seems to work...at least, so far.