Deactivate AfterUpdate of some keys

[Wayne-I-M]

I asked a similar question earlier today - sorry if it looks the same (it's
not)

It is possible to disable the AfterUpdate event unless the "enter" is
pressed - specifically not the arrow keys.

Example (you can try)

Create an unbound form
Create a option group with 2 buttons (Call it Frame0)
(It doesn't matter whats in the options)
Create 2 text boxes. (call them txt1 and txt2)

In the after update of the option group put this.

Private Sub Frame0_AfterUpdate()
Select Case Me!Frame0
Case 1
Me.txt1.BackColor = vbRed
Me.txt2.BackColor = vbBlack
Case 2
Me.txt2.BackColor = vbRed
Me.txt1.BackColor = vbBlack
End Select
End Sub


You will see the after update event is fired without using the enter key.
This is only a very simple example of something I am trying to achieve (some
users don't want to use the mouse so I need to de-activate the AfterUpdate of
the arrows or they will not be able to navigate the form)

Is there any way round this??

 

[Douglas J. Steele]

But look at the buttons in Frame0. They're changing, therefore you ARE
updating the frame.

Of course, that's all you're updating: you're not updating the table until
you leave the record.

 

[Wayne-I-M]

Hi Douglas

The problem is that the AfterUpdate of this form options is a set focus to a
subform (the subform is based on another table) so it does update the table.
So as soon as you enter the option group (unles you use the mouse) you action
the event and move out of the main form as you can't navigate to the 2nd
option without causeing the afterupdate event.

Don't worry though - I have told them I don't think it's possible.

I think this may be just one of those things that is beyond my skill level.

Oh well not to worry

Oh well worth a try


--
Wayne
Manchester, England.

But look at the buttons in Frame0. They're changing, therefore you ARE
updating the frame.

Of course, that's all you're updating: you're not updating the table until
you leave the record.

 

[Dave Smith]

Wayne,

I think your problem here is you are using the wrong event as your trigger
to navigate to your subform. Try using the Exit event instead. This will
free up the AfterUpdate to do nothing or something else, but will not force
the SetFocus until you Tab or Enter out of the Option Group.

HTH,

Dave Smith

 

[Wayne-I-M]

Oh my god. LoL

Thanks Dave. I have spent all day coming up with madder and madder moduals
and vba (even tried 3 cups of coffee one after the other to see if that
worked). I din't even think about reversing the tab order - which will make
your suggestion work perfectley.

Ha Ha you have to laugh.

The actual "event" is .......
The user inputs an amount into an unbound box
Selects either Credit or Debit (option group).
The event is then to insert this amount into the table field. (which is why
it is important that event is not fired until the correct option is selected)
Navigate to the subform (amounts can be made up of many items so this is
stored in a different linked table)
The option group Null's ready for the next input
etc
etc.

Your suggestion will make the whole thing work without the mouse.

Many thanks

 

[Pat Hartman \(MVP\)]

If they can be persuaded to give up the option group for a combo, you won't
have a problem. They tab into the combo and type c or d rather than using
the enter key to select as you must do with the option group.

 

[Wayne-I-M]

Thanks for the good suggestion Pat.