what's wrong with before update event procedure

[alekm]

Hi,
here is my code event procedure for a check box. I want to allow some users
to change its state and to prevent otheres from change it. Is there any way I
can ban that SendKeys "{ESC}" line? That line is the only way it works not
ending in the loop (you press anything on the form, msgbox pops up again),
but I don't see why??


Private Sub MyCheckBox_BeforeUpdate(Cancel As Integer)

If currentuser <> "RightUser" Then

MsgBox ("You are not right user. You don't touch this check box.")
Cancel = True
SendKeys "{ESC}"
' without last line msgbox pops up again and again when you press
' anything on the form
' only escape key stops it. Why?!

End If

End Sub

Any solutions?
Thanx

alekmil

 

[Krzysztof Naworyta]

Juzer alekm <[email protected]> napisa³

| here is my code event procedure for a check box. I want to allow some
| users to change its state and to prevent otheres from change it. Is
| there any way I can ban that SendKeys "{ESC}" line? That line is the
| only way it works not ending in the loop (you press anything on the
| form, msgbox pops up again), but I don't see why??
|
|
| Private Sub MyCheckBox_BeforeUpdate(Cancel As Integer)
|
| If currentuser <> "RightUser" Then
|
| MsgBox ("You are not right user. You don't touch this check
| box.") Cancel = True
| SendKeys "{ESC}"
| ' without last line msgbox pops up again and again when you
| press ' anything on the form
| ' only escape key stops it. Why?!
|
| End If
|
| End Sub

In fact a checkbox (as an option button and a toggle butoon) has not
BeforeUpdate event.
This event triggers in the same moment as AfterUpdate (and OnClick) and
can not be canceled.

You can use AfterUpdate event intead, changing wrong value:

Private Sub MyCheckBox_AfterUpdate()

If currentuser <> "RightUser" Then
MsgBox "Bla bla..."
With MyCheckBox
if .Value = True then
.Value = False
end if
'or:
'.Value = Not .Value
End If

End Sub




--
KN

archiwum grupy:
http://groups.google.pl/advanced_search
(grupa: pl*msaccess)

 

[Dirk Goldgar]

Hi,
here is my code event procedure for a check box. I want to allow some
users
to change its state and to prevent otheres from change it. Is there any
way I
can ban that SendKeys "{ESC}" line? That line is the only way it works
not
ending in the loop (you press anything on the form, msgbox pops up again),
but I don't see why??


Private Sub MyCheckBox_BeforeUpdate(Cancel As Integer)

If currentuser <> "RightUser" Then

MsgBox ("You are not right user. You don't touch this check box.")
Cancel = True
SendKeys "{ESC}"
' without last line msgbox pops up again and again when you press
' anything on the form
' only escape key stops it. Why?!

End If

End Sub

You don't need SendKeys, you can use

Me.MyCheckBox.Undo

instead.

You need to undo the change to the checkbox because, although setting
Cancel=True disallows the update, the user's change to the checkbox value is
still pending, and Access will keep attempting to reapply it until you undo
it, whether by the .Undo method or by pressing/sending the Escape key.

 

[John W. Vinson]

Hi,
here is my code event procedure for a check box. I want to allow some users
to change its state and to prevent otheres from change it. Is there any way I
can ban that SendKeys "{ESC}" line? That line is the only way it works not
ending in the loop (you press anything on the form, msgbox pops up again),
but I don't see why??


Private Sub MyCheckBox_BeforeUpdate(Cancel As Integer)

If currentuser <> "RightUser" Then

MsgBox ("You are not right user. You don't touch this check box.")
Cancel = True
SendKeys "{ESC}"
' without last line msgbox pops up again and again when you press
' anything on the form
' only escape key stops it. Why?!

End If

If you don't want a user to check a checkbox, don't LET them check it in the
first place!

Try putting code in the Form's Current or Load event:

Me!MyCheckbox.Enabled = (CurrentUser = "RightUser")

 

[Krzysztof Naworyta]

Juzer BruceM via AccessMonster.com <u54429@uwe> napisał

| A check box as an option group control does not have Before Update, but
| a single check box bound to a table field does.

You are wrong
Single checkbox can have BeforeUpdate subrutine but it does not work!
You can not take OldValue for example. You can not cancel this event.


| If you use the After Update event as you have shown the value will be
| updated, and the After Update code will run again, which means the
| value will be updated, and the After Update code will run again....
| The user will be able to do nothing but click the message box button
| over and over.

You are wrong!
Updating any control from code NEVER triggers AfterUpdate event.

 

[Krzysztof Naworyta]

Juzer Krzysztof Naworyta <[email protected]> napisaÅ‚

|| A check box as an option group control does not have Before Update, but
|| a single check box bound to a table field does.
|
| You are wrong
| Single checkbox can have BeforeUpdate subrutine but it does not work!
| You can not take OldValue for example. You can not cancel this event.

Ups! I was wrong!!! Sorry!

 

[Dirk Goldgar]

Juzer BruceM via AccessMonster.com <u54429@uwe> napisał

| A check box as an option group control does not have Before Update, but
| a single check box bound to a table field does.

You are wrong
Single checkbox can have BeforeUpdate subrutine but it does not work!
You can not take OldValue for example. You can not cancel this event.

You are wrong. <g>

For a standalone checkbox, the BeforeUpdate procedure does work. If the
checkbox is bound, its .OldValue property works just fine, and you *can*
cancel the event. However, you must also Undo the checkbox if you want it
to revert to its original value.

 

[Rick Brandt]

If you don't want a user to check a checkbox, don't LET them check it in
the first place!

Try putting code in the Form's Current or Load event:

Me!MyCheckbox.Enabled = (CurrentUser = "RightUser")

I'm assuming that this would be the proper method according to standard UI
practice, but in my experience disabling a control is likely to generate a
support call of "why is this control disabled?" whereas using BeforeUpdate
to display a message explaining why they are not allowed to use that control
does not.

 

[John W. Vinson]

I'm assuming that this would be the proper method according to standard UI
practice, but in my experience disabling a control is likely to generate a
support call of "why is this control disabled?" whereas using BeforeUpdate
to display a message explaining why they are not allowed to use that control
does not.

I should have added that setting its Visible property to no might be even more
effective: the user won't complain about being unable to click a checkbox if
they can't even see it!

Good point though. If it's important that the box be visible but protected,
the BeforeUpdate event would indeed be less user hostile.

 

[Krzysztof Naworyta]

BruceM via AccessMonster.com wrote:


(...)
| I want to point out that my tests
| with Access 2003 show that updating the check box from code in its
| own After Update event as you showed does indeed trigger its After
| Update event again.

I can not confirm it!