Ascii

[ajetrumpet]

Adam,
Do you have the Form's KeyPreview property set to YES?

NO

What are you actually trying to prevent the user from doing? Moving fields by pressing enter? Moving records by pressing enter? If you go into Tools=>Options you can change the behavior of the enter key.

Got it now. And yes, it was simple, probably too simple. Thanks Keith.

Right now I am using A2007, and I don't really like the ribbon, as it takes away from the easy navigation of the menu lists.

I am still pondering though, why none of the code that I tried above has worked. Does anyone think it is just not relevant? I wonder if other keys can be disabled by VB? I just changed the option in tools for the enter key, but there is obviously no other keys' behavior specified in those options. Makes me wonder if "enter" has no place in Ascii, although the VBA help says it does...

 

[ajetrumpet]

Guess what!?

I have disabled the movement only of the enter key.

When I am in a form, and I press enter, it highlights the value that I am on, and enters a new record, but the cursor doesn't move, and the form does not move to a new record. So, problem still not solved...

 

[Banana]

Like KenHigg asked, Can you please exactly describe what you are trying to accomplish by not moving to a new record then wanting to move to new record after a point?

Seem to me we're trying to solve a wrong problem....

 

[RuralGuy]

Maybe this link will offer some additional ideas on the issue.

 

[ajetrumpet]

Can you please exactly describe what you are trying to accomplish by not moving to a new record then wanting to move to new record after a point?

Simple Solution needed - Preventing the press of the "Enter" Key, while on a form, from entering the form data into the underlying table. It doesn't get much simpler than that.

RuralGuy,

The FAQ doesn't provide much info. Nothing in the code resembles what I need. Thanks though!

I'm starting to think that I am dealing with a program setting / option, rather than an Ascii, or VB Constant issue...

 

[boblarson]

Simple Solution needed - Preventing the press of the "Enter" Key, while on a form, from entering the form data into the underlying table.

Using code on the Before Update event of the form can prevent that. Can't get much simpler than that.

 

[RuralGuy]

The Enter key by itself does *not* update the underlying record. Only closing the form or moving to another record will cause a Dirty record to be updated and ghudson's "Better Mouse Trap" will prevent that.

 

[Banana]

I agree with Bob & RuralGuy.

This is exactly why we have BeforeUpdate event.

 

[ajetrumpet]

Using code on the Before Update event of the form can prevent that. Can't get much simpler than that.

Well that's great Bob, but what code? I've already tried it all, remember?

The Enter key by itself does *not* update the underlying record.

Not in my database Sir. I'm afraid it's backwards for me.

 

[Banana]

Here's a simplest code to put in BeforeUpdate Event just to try it out.

Sub Form_BeforeUpdate(Cancel As Integer)

Cancel = True

End Sub

This will prevent *any* records from ever updating, no matter what you do! Enter key, page up/down, and all that! All won't work!

Now, read Ghudson's better Mousetrap a bit more careful, download the sample and see how his model works- he *does* uses BeforeUpdate event and check if a condition is satisfied before proceeding with an update.

 

[ajetrumpet]

Congrats Banana! Your code does exactly what you said. Amen!

Regarding Ghudson's FAQ: Here is the code...

Private Sub Form_BeforeUpdate(Cancel As Integer)
On Error GoTo Err_Form_BeforeUpdate
    
    Me.tbHidden.SetFocus
    
    If Me.tbProperSave.Value = "No" Then
        Beep
        MsgBox "Please Save This Record!" & vbCrLf & vbLf & "You can not advance to another record until you either 'Save' the changes made to this record or 'Undo' your changes.", vbExclamation, "Save Required"
        DoCmd.CancelEvent
        Exit Sub
    End If

Exit_Form_BeforeUpdate:
    Exit Sub

Err_Form_BeforeUpdate:
    If Err = 3020 Then  'Update or CancelUpdate without AddNew or Edit
        Exit Sub
    Else
        MsgBox Err.Number, Err.Description
        Resume Exit_Form_BeforeUpdate
    End If

End Sub

Now, where in that code does it say...

If "Enter Key is Pressed" Then
  "Do Nothing"

...???

All of the above code just issues msgboxes and beeps on conditionals. There is nothing there about disabling the function of a key!!

 

[boblarson]

There is nothing there about disabling the function of a key!!

In this case the Before Update event will be able to handle any validation and you can stop an update from happening from wherever, key press or not. It doesn't matter. Test for what needs to happen and it will take care of it regardless of whether they pressed an enter key or hit the navigation button, or closed the form.

 

[Banana]

The point of the exercise I gave you in my last post was to show you that you do *not* need to trap for a key to prevent an update.

It's much more logical to prevent a update if a textbox is missing a value, and you can give a specific message box to your user telling them that they must fill this value in, than to disable enter key and get complaints from your users asking why this isn't working at all.

So let me quote you:

Simple Solution needed - Preventing the press of the "Enter" Key, while on a form, from entering the form data into the underlying table.

This is *exactly* what BeforeUpdate is for- to trap for events where you do not want to update anything to the table; if you trapped for enter key, you'd still leak on page down/up, pressing a save button, and so many more. Ghudson's mousetrap, using BeforeUpdate, will catch *any* of that events, so all you need is to specify what conditions you want to satisfy before allowing the update to occur.

Did that make sense?

 

[Banana]

One more benefit of using conditions instead of trapping for a specific event such as pressing enter or navigation buttons or whatever:

You give your users maximum flexibility without compromising data integrity. I know that my users do not always use tab order to enter the records. Some start at a random field then go around the form in a random order, perhaps because they have their own list in a different order, or other user may do it completely backward or whatever. But guess what, I don't care because BeforeUpdate will stop any bad update cold so I know that my users will always input what is required, *regardless* of how they filled it out.

Trapping a specific event, OTOH, will make your users pull their hairs out of their head as they furiously press the enter key in vain, not knowing why they can't go any further, and you will scream in agony when you see bad data creeping in your tables when they figure out that they can just use other method of navigating the forms.

 

[ajetrumpet]

The point of the exercise I gave you in my last post was to show you that you do *not* need to trap for a key to prevent an update.

I understand this, but that is beside the point I'm trying to get at.

if you trapped for enter key, you'd still leak on page down/up, pressing a save button, and so many more.

I understand this too, but I am not concerned with logic or correctness here! All I want to know is how to trap the d*** key!!

And Bob, as for your reply...

In this case the Before Update event will be able to handle any validation and you can stop an update from happening from wherever, key press or not. It doesn't matter. Test for what needs to happen and it will take care of it regardless of whether they pressed an enter key or hit the navigation button, or closed the form.

I am totally not following you. But then again, as I have said above, I do not care about validation procedures here. Maybe one of you could write a one or two-liner Sub that you would use if you were trying to disable the key?

I should mention too, that this question of mine has nothing to do with work processes, users, or anything else that is technical or business related. This is just something I want to know, but can't, for the life of me, figure out! Thanks!