Give meaningful names to controls on form?

  • Thread starter Thread starter Ann Scharpf
  • Start date Start date
A

Ann Scharpf

I am looking in the help and in the newsgroups & must be missing something.
Is it possible to assign a meaningful name to a control you add to a form?
Combo30 and Combo42 just aren't terribly useful.

Thanks in advance.
 
Open in design view, right click, select Properties at the bottom. Click on
All and then in Name. Edit it to your desire, avoiding reserved words or
unallowed characters.
 
Thanks for answering.

Would it be a NoNo to give the control the same name as the field it's based
on? Or should I do something like LabCatCombo to distinguish it?

Thanks.
 
Ann Scharpf said:
Thanks for answering.

Would it be a NoNo to give the control the same name as the field it's
based
on? Or should I do something like LabCatCombo to distinguish it?
Click to expand...


This is a warmly, if not hotly, debated question. Some people believe that
you should tag the control name with a prefix or suffice to identify it and
distinguish it from the field itself. There's a fairly standardized set of
prefixes that people tend to use: "cbo" for a combo box, "txt" for a text
box, "lst" for a list box, "chk" for a check box, and so on.

However, in all normal circumstances it does no harm to name the control the
same as the field, so long as the field has an acceptable name. This is
what I do for all bound controls, unless I intend to do something odd to it
like switch its controlsource around, or otherwise have a semantic need to
distinguish the control from the field. That's the side of the debate I'm
on.
 
Linq Adams via AccessMonster.com said:
Actually there is a reason not to have the control and its Control Source
named the same, but I can't remember what it is exactly! It has to do with
something entered in the Properties sheet, maybe a control's Default Value
or
Control Source, that references another control. Having both named the
same
confuses Access as to which you're trying to reference.
Click to expand...


Linq, you're going to have to be more specific than that if you want me to
buy it. <g> The only complication I know of is that, if you give a control
the same name as a field in the form's recordsource, then the control *must*
be bound directly to that field -- not unbound, not bound to some other
field, not bound to some expression involving the field, but to the field
itself. Aside from that quite natural and understandable restriction, I
have never seen nor heard of a case of Access getting confused about this.

*People* get confused when they had a control named "Foo" bound to field
"Foo", and then they change the controlsource to "='Something and ' &
[Foo]", and all of a sudden it starts giving them #ERROR. But that's not
really Access's fault, now is it? The user has created a logical ambiguity
that Access is not able to resolve. Then user needs to rename the control
to relieve the ambiguity.
 
Linq said:
Actually there is a reason not to have the control and its Control
Source named the same, but I can't remember what it is exactly! It
has to do with something entered in the Properties sheet, maybe a
control's Default Value or Control Source, that references another
control. Having both named the same confuses Access as to which
you're trying to reference.
Click to expand...

No, it doesn't. There are people who prefer to use different names between
fields and the controls they are bound to. There is no *functional* reason
to do so.
 
Thank you, Dirk & Rick. I think I will add a suffix to my controls so I
don't get myself confused. But it's good to know that I'LL be the one
confused and not Access if I forget to add the suffix.
 
Back
Top