[AccessD] Code Help Please

A.D.Tejpal adtp at airtelmail.in
Fri Mar 7 02:38:42 CST 2008


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>>


More information about the AccessD mailing list