A EVEN BETTER mouse trap?

[Kronos]

First off sorry about the really bad layout…..I don’t know how to do all the fancy stuff but really wanted to share this because it seams like a lot of people wanted help with this.

So here is what I have going on.

I have a form to add a record, and I have a number of fields, then an “Add Record” button and a “Cancel Record” Button. What I wanted to do was:

A: Stop the form from going to another “New Record Form” when moving the mouse wheel
B: Stop the form from going to another “New Record Form” when pressing the “Tab” key


Here is what you got to do to solve the mouse problem:

1.) Create a field in the form that has the Name “MouseWheel Move”, and set the “Visible” property to “No”
2.) Enter the Fallowing:

Private Sub Form_Load()

Me![MouseWheel Move] = "No"​

End Sub​

3.) Enter The Fallowing:

Private Sub Form_MouseWheel(ByVal Page As Boolean, ByVal Count As Long)

Me![MouseWheel Move] = "Yes"​

End Sub​

4.) Enter The Fallowing:

Private Sub Form_BeforeUpdate(Cancel As Integer)

If Me![MouseWheel Move] = "Yes" Then

DoCmd.CancelEvent
Me![MouseWheel Move] = "No"​

End If​

End Sub​

Here is what you got to do to solve the Tab problem:

The last item on my form is my “Cancel” button; so when the focus is on my “Cancel” button (ie. the last item on the form) and I press tab I want the focus to go to the first field on my form.

Private Sub Cancel_Button_KeyDown(KeyCode As Integer, Shift As Integer)

If KeyCode = 9 Then

Me![Field Name for the First Item on the Form].SetFocus​

End If​

End Sub​

One more thing, I am using Microsoft Access 2002 (10.6771.6735) SP3 and it works fine

 

[elbweb]

i just wanted to throw in my two cents and say that in my opinion the best way to get around all of these access 'features' is to just stay away from bound forms completely, all they do is cause trouble from what i've seen.

if you need some info on how to do everything without a bound form, feel free to pm me, it is extreamly simple, takes a little bit longer, but you have a lot more control over what is happening, and you dont need to worry about access screwing things up anymore.

 

[Banana]

If that's the case, why not use VB .NET, C# or Java IDE?

I'm led to understand that what makes Access stands out is the bound forms?

Kronos, how is that better than Ghudson's mousetrap which catches mouse wheels, tab and other events such as pgup, pgdown, F9 and then some more?

 

[elbweb]

yes it is, but its also more then that, a big part for me is the reports, and the ease of distribution, bound forms are great, but when you get into situations where you need to deal with things like this, it would make more sense to me to just go beyond the bound forms.

 

[Kronos]

I admit it's not, I just used the title so that the search will pull up my thread with his to give people more options, I could have just did a reply to his, but my format is really long and doesn't have those cool code boxes which make it nice and ordily

 

[Banana]

Kronos,

You can easily make boxes; you just add this:

[code]Your Stuff Here [/code]

which would look like this:

Your Stuff Here

Also, to discover other trickies, click on the quote button. This will expose the code behind the tricks you want to use yourself.


elbweb,

and what about the possiblity that you are introducing more errors/bugs/flaws by doing the hard work that Access could do for free?

There are indeed times to use unbound controls/forms. Heck, I have few of them, but I try to use it sparingly as possible because that means less coding=less bugs. *shrugs*

 

[llkhoutx]

The suggested code does not work for form records that are not "dirty" - no "BeforeUpdate" event is fired.

I tried the code on single forms, nested 3 deep, and it worked fine.

It would not work on a continuous subform, but in that circumstrance, wheel scrolling if preferred. I even tried the trapping the continuous form well scroll on the ONCurrent event. Still didn't work.

 

[missinglinq]

Using unbound forms in Access does, indeed, do away with much of the advantage/reason to use Access! Anyone happy with the aggravation of unbound data forms should, indeed, stick with VB6 or VB.Net and use a non-Access backend. This also has the advantage of allowing an exe file to be compiled, being able to run on systems that don't have Access installed, and providing security that you really can't get with Access. The only downside is that unbound forms require a huge amount of work!

Keeping Tabbing from going to the next/new record is as simple as going to going to
Properties - Other and setting the Cycle Property to Current Record.

The gold standard in locking the mouse scroll wheel, successfully used by literally thoudsands of developers for years, is Stephen Lebans hack, available thru a sample database at

http://www.lebans.com/mousewheelonoff.htm

It works in all forms, consists of a DLL that is included, a single function, and requires one line of code to be placed in Form_Load event of a form. If you have a form that always opens first, such as a splash screen, you place the single line of code there and the MouseWheel is locked for all subsequently opened forms, until the database itself is closed.

 

[llkhoutx]

As a contract developer, we've found that new DLLs are not only frowned upon, but absolutely prohibited, by enterprise non-programmer managers.

After about a year with VB.Net, I've come to appreciate unbound forms. However, Access provides us with a lot of bread, butter and beer. Managers appreciate the big ROI of Access database development.

.Net doing away with "subforms" troubled us at first. Now, we're a firm believer.

One of the days, we're going to develop a portable set of unbound form tools for our use with Access unbound forms. We're locked into Access development contracting because we've done it so long.

Cheers.