Option Group and UNDO

[Reggie Laffond]

I saw a post on this dated 10/25/04 with replies by MARSH but I don't think
it was resolved. I'm having a similar problem but I didn't want to hijack
the thread.

Access 2000 - When a user changes the value of an option group by selecting
a different radio button I want to confirm that the user really wants the
change. The radio buttons are definitely members of the frame because the
value in the field bound to the option group has been changing correctly up
until now. Here is the code I am adding.

Private Sub optTstSide_BeforeUpdate(Cancel As Integer)
If MsgBox("Are you sure you want to change the test side value?",
vbYesNo) = vbNo Then
Me.optTstSide.Undo
End If
End Sub

If the user answers the message box with vbNo the "Me.optTstSide.Undo" code
runs but the value of the option group still changes to the value of the new
radio button selected.

I put this in the option group BeforeUpdate event because I want to prompt
the user immediately when the value is changed and not wait until the form's
BeforeUpdate event.

I even tried Me.optTstSide.Requery after the undo but no luck.

Thanks in advance.

 

[Guest]

Reggie:
Try the following:
Private Sub optTstSide_BeforeUpdate(Cancel As Integer)
If MsgBox("Are you sure you want to change the test side value?",
vbYesNo) = vbNo Then
Cancel = True
Me!optTstSide.Undo
End If
End Sub

Note the additional line of code (Cancel = True), and the replacement of the
dot in "Me.optTstSide.Undo" with a "!".

TL

 

[Reggie Laffond]

Cancel=True solved the problem. Thanks a lot.

I've always noted that sometimes form names and controls names are connected
with a "." and sometimes with a "!". I've always seen collections (the Forms
collection for example) and members of collections separated with a "!" (ex.
Forms!frmMain).

Is there a simple explanation about when to use which? Or is there some good
documentation I can read?

Thanks again.

 

[Dirk Goldgar]

Cancel=True solved the problem. Thanks a lot.

I've always noted that sometimes form names and controls names are
connected with a "." and sometimes with a "!". I've always seen
collections (the Forms collection for example) and members of
collections separated with a "!" (ex. Forms!frmMain).

It probably didn't actually matter in this case.

Is there a simple explanation about when to use which? Or is there
some good documentation I can read?

Here's my standard screed on the subject:

----------------- DOT VS. BANG -------------------
It's not so much a question of one or the other being "proper syntax",
but that they mean different things that nevertheless almost always give
the same result. As I understand it, the bang (!) notation specifically
denotes that what follows is a member of a collection; in this case, a
member of the form object's default collection, the Controls collection.
The dot (.) notation denotes that what follows is a property or method
of the preceding object. That would logically make the bang notation
"proper" and the dot notation improper.

But wait. Wherever possible, Access makes the controls on a form and
the fields in its recordsource all available as properties of the form.
It also makes the fields of the recordsource available via the bang
notation. I'm not sure exactly how it does this; maybe if a name is
not found in the Controls collection it checks the Fields collection of
the form's recordset as a fallback position. So for most practical
purposes Me!ControlName and Me.ControlName evaluate to the same thing,
and the timing tests I've seen suggest that there is little to choose
between them as far as execution efficiency is concerned. I seem to
recall that there is a very slight difference, but I can't remember
which way the advantage lies, and it's not much. There's a coding-time
advantage, however, to using the dot notation, as it makes the
"intellisense" dropdown lists available. That's a strong argument for
using the dot notation, in my book.

But wait again! I said above that Access makes the controls available
as properties "wherever possible". There are cases where it can't do
that. Specifically, it can't do it when there is already a property of
the same name as the control in question. For example, if your form
"Form1" has a control or a field foolishly named "Name", currently
displaying the value "John Doe", then executing this statement in the
form's code module:

Debug.Print Me!Name, Me.Name

will print

John Doe Form1

in the Immediate Window. So you must be careful not to use any reserved
words or built-in properties as names for your controls, if you want to
use the dot notation to refer to them. But then, you should avoid doing
that anyway, as it tends in general to confuse poor Access.

 

[Reggie Laffond]

Great explanation!

So bang (!) signifies a member of a collection and dot (.) an object's
property or method. But Access helps out whenever possible when you use the
wrong one.

I always avoid reserved words when naming controls so that's why I get away
with using the dot (.) most of the time. And I do love the dropdown list
when using the dot (.)

Thanks Dirk for taking the time to spell it out for me!

 

[Dirk Goldgar]

So bang (!) signifies a member of a collection and dot (.) an object's
property or method. But Access helps out whenever possible when you
use the wrong one.
Right.

I always avoid reserved words when naming controls so that's why I
get away with using the dot (.) most of the time. And I do love the
dropdown list when using the dot (.)

Me, too.

Thanks Dirk for taking the time to spell it out for me!

You're welcome.

 

[Guest]

I have the same problem in Access 2003, but setting Cancel = True isn't
setting the option group back to its original state. The option group
contains only 2 radio buttons:

Private Sub optScheduleType_BeforeUpdate(Cancel As Integer)
Cancel = fnUserCancelsUpdate("schedule type")
If Cancel Then Me!optScheduleType.Undo
End Sub

If the user chooses to cancel, fnUserCancelsUpdate returns True (in
desperation I tried using boolean and integer types in turn) correctly and
the Me!optScheduleType.Undo method is executed, but the radio button
selection in the option group remains as the user has just clicked, and does
not return to its original state.

Any help would be gratefully appreciated