MsgBox on Checkbox Before and After Update Event Behaviour

[kobamfo]

Hi Guys,
I have a Check box named "crypt" on a continuous form and I would like to pop up a message box depending on the value of the check box, Like this: If the Box is initially checked on load of the form and the user unchecked it, the message should say "...Click yes to continue or No to cancel" such that the click of "yes" would accept the User's unchecking of "crypt" and No would simply undo the update attempt. so I have this code

Private Sub crypt_AfterUpdate()
Dim Msg, Style, Title, Ctxt, Response, MyString
 
If crypt.Value = 0 Then
Msg = "Are You sure you have unlocked the PDF?" & _
"Click Yes to continue or No to Cancel"
 
Style = vbYesNo + vbExclamation + vbDefaultButton2
Title = "File Unlock Warning"
Ctxt = 1000
 
Response = MsgBox(Msg, Style, Title, Ctxt)
 
    If Response = vbYes Then
    MyString = "Yes"
    Cancel = True
 
Else
MyString = "No"
DoCmd.RunCommand acCmdUndo
    End If
End If
End Sub
 

The Problem is the reverse does not work! That is if "crypt" is in an unchecked state and the User checked it, on Click of "No" the Undo does not work. That is the check does not clear on Undo, Why?
Any Help, please.

Warm Regards.

[zmbd]

One would assume that this check box is in the details section of the form?
Is this control bound?

[TheSmileyCoder]

You have to be careful with the Docmd.Runcommand accmdundo, as that is to some degree context sensitive. I.e. the action that happens is based on what else has occurred prior to the action being taken.


Instead of using the AfterUpdate I would suggest you use the beforeupdate. In this case note that the value of the crypt field is the value it is going to have. Ie. if it was true, and you click it then the code will believe it to be false until you cancel it.

Your code also seems quite confusing. You have mystring which is not used and ctxt which is not used, and your lack of indentation makes it harder to view the logic. If crypt.value<>0 then nothing happens cause you haven't specified anything for that.

A simplified example:

Private sub crypt_BeforeUpdate(Cancel as integer)
 
  If vbYes= Msgbox("Did you intend to change the status",vbYesNo) then
    'Yes, don't do more
  Else
    'No so we cancel
    Cancel=True
    Me.Crypt.Undo
  End If
End Sub

[NeoPa]

Kobamfo:
That is the check does not clear on Undo, Why?

Simply put, because you have already applied the change. Undo, in any of its forms, only works on changes that have not yet been applied. As such, it would make better sense to handle this in the _BeforeUpdate() event procedure. That even has a special parameter in order to allow you to cancel the update if you determine it should be. {ControlRef}.Undo will handle the undo most appropriately, as it is specifically targeted to the control.

[DanicaDear]

Thank you. This helped me too. :-)

[NeoPa]

Hi Danica. Always nice to hear from you. Hope you and family are all doing well.

Nowadays, I would be clearer and say to use the Cancel parameter in the {Control}_BeforeUpdate event procedure for preference. {Control}.Undo is for macros or for code outside of the specific event procedure itself.

[TheSmileyCoder]

I beg to differ a bit. If a user selects a bad entry in say a combobox, perhaps a status that is not valid, I usually prefer to force the value back to the original value (Otherwise the user is forced to either select the old value (which he might not remember) or do a manual undo(esc))
So usually my code might be:

Private Sub SomeControl_BeforeUpdate(Cancel as Integer)
Msgbox "This status is not valid, while ...."
Cancel=True
SomeControl.Undo
End Sub

[NeoPa]

You're always welcome to differ Anders. However, in this case, I think you'll find that the .Undo is unnecessary as setting Cancel = True has the same effect anyway. It would probably act first as the Cancel value is only processed after the event procedure has completed, but I feel that the Cancel = True code is more appropriate from within an event procedure.

It makes more sense to use .Undo for objects which are not the object directly being handled.