Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Access 2003: Accessing a property of control causes "identity corruption"

2 views
Skip to first unread message

Yarik

unread,
Mar 12, 2008, 8:59:51 PM3/12/08
to
Hello all,

Here is the code that demonstrates an interesting phenomenon (this
code is for a simple form having just 3 controls - a labeled text box
and a command button):


-------------------------------------------8<---------------------------------------
Private Sub Command2_Click()

Dim ctl As control

For Each ctl In Me.Controls

Debug.Print "Control name.............: " & ctl.Name
Debug.Print "Is control itself........: " & (ctl Is
Me.Controls(ctl.Name))
Debug.Print "Control name.............: " &
ctl.Properties("Name")
Debug.Print "Is control still itself..: " & (ctl Is
Me.Controls(ctl.Name))
Debug.Print

Next

End Sub

-------------------------------------------8<---------------------------------------

The output is:


-------------------------------------------8<---------------------------------------
Control name.............: Text0
Is control itself........: True
Control name.............: Text0
Is control still itself..: False

Control name.............: Label1
Is control itself........: True
Control name.............: Label1
Is control still itself..: False

Control name.............: Command2
Is control itself........: True
Control name.............: Command2
Is control still itself..: False

-------------------------------------------8<---------------------------------------

Further experiments suggest that any attempt to access any property of
the control breaks what seems to be an invariant:

ctl Is Me.Controls(ctl.Name)

Unfortunately, I cannot find any hints (let alone explanations) of
such behavior in Microsoft's documentation. Is this a feature or a
bug? Did anybody encounter this problem and, ideally, any workaround?

Thank you,
Yarik.

P.S. I know that expression "ctl.Name" is not very good, because
"Name" is not an "official" property of Access.Control object.
Probably it is better to use the following expression instead:

ctl.Properties("Name")

But this does not change the essence of the problem. In fact, in the
light of the abovementioned problem with properties, it actually seems
to be dangerous to obtain control's name via its Properties
collection. :-(

Allen Browne

unread,
Mar 12, 2008, 9:34:58 PM3/12/08
to
Yes, that's an interesting curiosity.
Clearly something going wrong in the Access object handling.

You may also be intested to know that back in Access 97, the first one
produced False as well, i.e. this was not recognised as true:
(ctl Is Me.Controls(ctl.Name))

So my guess is that Microsoft patched up an issue here, but failed to
address the root cause of the problem.

My suggestion would not be to use Is to test controls, but to test their
names. Since a form/report can't have have 2 controls with the same name,
that should correctly identify them.

Re your final comment, I don't see a problem with using ctl.Name. (I would
only be likely to use the Properties collection explicitly if I were looping
through the properties, or passing a string for the property name.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Yarik" <ya...@garlic.com> wrote in message
news:be12a65c-c625-479e...@s13g2000prd.googlegroups.com...


> Hello all,
>
> Here is the code that demonstrates an interesting phenomenon (this
> code is for a simple form having just 3 controls - a labeled text box
> and a command button):
>
>
> -------------------------------------------8<---------------------------------------
>Private Sub Command2_Click()
>Dim ctl As control
>For Each ctl In Me.Controls
> Debug.Print "Control name.............: " & ctl.Name
> Debug.Print "Is control itself........: " & (ctl Is
> Me.Controls(ctl.Name))
> Debug.Print "Control name.............: " & ctl.Properties("Name")
> Debug.Print "Is control still itself..: " & (ctl Is
> Me.Controls(ctl.Name))
> Debug.Print
>Next
>End Sub

[snip]

Yarik

unread,
Mar 14, 2008, 11:00:05 PM3/14/08
to
Hi Allen!

Thank you for the prompt response!

On Mar 12, 6:34 pm, "Allen Browne" <AllenBro...@SeeSig.Invalid> wrote:
> My suggestion would not be to use Is to test controls, but to test their
> names. Since a form/report can't have have 2 controls with the same name,
> that should correctly identify them.

Yup, that's exactly what I ended up doing. Not as nifty as using "Is",
but otherwise works just fine. :-)

> Re your final comment, I don't see a problem with using ctl.Name. (I would
> only be likely to use the Properties collection explicitly if I were looping
> through the properties, or passing a string for the property name.)

Maybe the real reason why I don't like to use ctl.Name is that VB6
compiler appears to be treating the Access.Control class just like it
does with "amorphous" Object class: it does not care what you write
after the dot! Even if you write something like this

Dim ctl As Access.Control
Debug.Print
ctl.RidiculousPropertyNameThatOnlyAnInsanePersonWouldInvent

compiler blissfully ignores it and does not warn about possible
problem. (I mean compile-time diagnostics, not run-time errors, of
course.)

(How did they manage to make the Access.Control class so "amorphous"
anyway?)

But then again: VB6 is such a joke in terms of compile-time error
checking... Another small issue practically does not make a difference
anymore. :-(

0 new messages