Jim Lawrence
accessd at shaw.ca
Fri Mar 7 11:02:03 CST 2008
Hi A.D.Tejal:
You have really done a lot of research into this... impressive.
Jim
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.Tejpal
Sent: Friday, March 07, 2008 12:39 AM
To: Access Developers discussion and problem solving
Cc: A.D.Tejpal
Subject: Re: [AccessD] Code Help Please
Naming of Bound Controls On Forms / Reports
(Visa Vis Control Source)
================================
Max,
So long as certain precautions are observed, it should be perfectly ok
to name a pure bound control the same as the field serving as its control
source. Done correctly, it should never cause any problem. No need to get
unduly overwhelmed by advice to the contrary.
2 - This subject was examined recently (Nov-Dec 2007) in Access MVP's
forum, culminating in comprehensive guidelines, placed at the end of this
post. These guidelines are now displayed at Steve Schapel's web site as well
(url below):
http://accesstips.datamanagementsolutions.biz/controlname.htm
3 - Certain interesting findings related to controls on forms / reports
are also placed below.
3.1 - Forms - If a field name in record source is referred in VBA code
whether directly or with Me qualifier followed by dot, bang or parenthesis
(containing field name in a string), and no control having this name is
physically present on the form, the code refers directly to the field and
value is the only property exposed.
3.2 - Forms - If a bound control having its name identical to the
control source is present on the form and this name is referred in VBA code
whether directly or with Me qualifier, it automatically refers to the
control. Intellisense exposes all the properties for the control. Value
(which was the only available property when field was being referred)
becomes the default property of this control. In other words, a bound
control having its name identical to control source acts somewhat like a
super-incarnation of the field itself, with additional properties over and
above the original Value property.
3.3 - Forms - If an unbound control having its name identical to a field
in record source is present on the form and this name is referred in VBA
code whether directly or with Me qualifier, it automatically refers to the
control (not the field in record source)
3.4 - Forms - If a bound control having its name identical to the
control source is present on the form and it is desired that VBA code should
refer only to the source field (not the control), it can be done by using
the syntax: Me.Recordset("FieldName")
Note - The value returned by using Me.Recordset("FieldName") is always
in synch with the current record (Absolute position of recordset matches
current record). On the other hand, if RecordsetClone were used, it would
always open at the first record position and return the value accordingly,
irrespective of current record position (additional code is needed to
navigate to a particular record).
3.5 - Forms & Reports - Calculated controls having expressions using
names of controls / fields:
(a) In plain expression, if a control having that name exists
physically, the control prevails. If no such control exists, field gets
picked up.
(b) If aggregate expression is involved (e.g. Sum() etc.), the field
prevails even if a control of identical name exists.
3.6 - Reports - Fields in record source are not amenable to direct
reference via VBA code. Only controls actually existing on the report are
reliably recognized in VBA.
4 - Guidelines - as evolved in Access MVP's forum
=======================================
Naming of controls w.r.t. field names (General Guidelines)
----------------------------------------------------------
1 - For controls referenced in code or expressions, the names should not
be the default names such as "text13". It is best to modify the default name
to something meaningful that eases maintenance of application.
2 - An unbound or calculated control should not have its name identical
to any of the fields contained in the record source. As a standing
precaution, suitable prefix like Txt (or txt), Cbo (or cbo) etc should be
used while naming such controls.
3 - It is perfectly Ok if the name of a pure bound control is the same
as its control source (unless, for some reason, you need a different name
for the bound control - see para 4 below). It can also prove convenient in
readily distinguishing the bound controls from others. However, in such an
arrangement, care has to be exercised on following lines:
(a) If the role of an erstwhile bound control bearing a name
identical to its control source is subsequently changed to that of an
unbound or calculated control, its name should be modified simultaneously
(including suitable prefix as per 2 above) so as to differentiate it from
field names.
(b) If the control source of a bound control is subsequently
changed, its name should be changed simultaneously, matching the new control
source.
4 - There is no objection however, to rename even bound controls, say by
prefixing with Txt (or txt), Cbo (or cbo) etc. if the developer is keen to
do so. In such a case, care should be taken to use the actual field name
(and not the control name) while using the content in aggregate expressions
in calculated controls e.g. =Sum([FieldName]). It would also be desirable to
give meaningful names to such calculated controls e.g. txtTotal, or txtAvg
etc.
5 - For a control bearing the name of a particular field in record
source, NEVER bind it to some other field.
Note - In allowing the names of bound controls to be identical with the
control source, if the developer is not confident enough that the discipline
envisaged in para 3 (a) & (b) above would be strictly observed, it might
prove safer to rename all such controls in the beginning itself, as per para
4 above. In order to make such a task less taxing, suitable tool like Arvin
Meyer's FixNames utility (link given below) can be used if desired.
http://www.datastrat.com/Download/FixNames2K.zip
==========================================
Best wishes,
A.D.Tejpal
------------
----- Original Message -----
From: Max Wanadoo
To: 'Access Developers discussion and problem solving'
Sent: Friday, March 07, 2008 02:40
Subject: Re: [AccessD] Code Help Please
Sounds like a good disciple then. I will start to adopt it.
Thanks all
Max
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Thursday, March 06, 2008 9:05 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Code Help Please
I'm with Patricia, even in dotNet. I may be the only one in my shop who
renames religiously, but I do it. There's little I hate as much as
switching back and forth between design view and the code window trying to
figure out which control I'm addressing when just a minor amount of time
at
the start lets me know exactly which control I need to address without all
that effort. Plus circular references can pop up unexpectedly in places
where they're harder to track down, so I buy insurance.
Charlotte Foust
<<Snipped>>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com