Yes, there are quirks that show up intermittently here.
You can work around the problem with:
strName = Me!CustomerName
Access tries to be too clever. If you have both a field and a text box named
CustomerName, then
Me.CustomerName
is resolved as an object of type TextBox. If there is no text box by that
name, the reference is resolved as an object of type AccessField, and the
problem is associated with that type. For example, if you enumerate the
Controls of the form, naturally enough those that are just an AccessField
are not listed, and are not counted in Me.Controls.Count. However, the
reference:
Me.Controls("CustomerName")
*does* work, even though we just showed that the AccessField is *not* part
of the Controls collection.
The bug you refer to seems to be related to this inconsistent attempt to
recognise things that are but are not part of the collection. It works
sometimes. Then for no apparent reason, you make an unrelated design change
and it suddenly stops being able to recognise the AccessField. The best
workaround is to *always* use the bang and not the dot to reference the
AccessFields. The annoying part is that misspellings are not caught at
design time (which is why I generally prefer the dot), but it seems the only
foolproof way around this issue.
There's a much worse bug related to this in Access 2002 and 2003. Most
people don't display the foreign key in a subform because it's shown on the
main form. If the field named in the subform control's LinkChildFields is an
AccessField (i.e. there is no control for it), Access will not merely reject
the reference one day, but will start crashing, i.e. "shut down by Windows;
sorry for the inconvenience." In these versions, you *must* include a text
box for your foreign key fields in the subform (Visible = No), to avoid this
serious problem with the AccessField type.
HTH.
--
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 Mezheritskiy" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> Please, help me to solve this puzzle:
>
> (1) We have a heap of legacy Access 2000 code that frequently uses the
> following trick: when a value of some bound control is necessary, the
> code refers to that control using its "Control Source" property value
> (instead of, say, using the control's "Name" property value). For
> example, if there is a bound text field named "txt88" and having its
> "Control Source" set to "CustomerName" (which is a name of the
> corresponding field in the underlying recordset), the code looks like
>
> strName = Me.CustomerName (a)
>
> instead of "classic"
>
> strName = Me.txt88 (b)
>
>
> (2) We have two computers with installations of MS Access 2000 + MS
> Office Developer 2000 where this code is being maintained/developed.
>
>
> The puzzle is that on one of those computers the code like (a)
> compiles without a hitch, but on another computer each occurence of
> code like (a) causes VBA compiler to issue an error ("Method or data
> member not found"). Could somebody shed some light of why could
> compiler on the second computer complain about code like (a)?
>
> (The only difference between two computers and their software
> configurations that I can easily describe is that the second computer
> -- where compiler complains -- was set up recently, whereas the first
> computer has been set up a long time ago and nobody remembers what
> could have been installed there after basic MS Office + MS Office
> Developer stuff.)
>
>
> Thank you,
> Yaroslav.
Similar Threads
