Access 2003: Accessing a property of control causes "identitycorruption"

  • Thread starter Thread starter Yarik
  • Start date Start date
Y

Yarik

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. :-(
 
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.)
 
Hi Allen!

Thank you for the prompt response!

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.
Click to expand...

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.)
Click to expand...

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. :-(
 
Back
Top