O'Connor, Patricia (OTDA)
Patricia.O'Connor at otda.state.ny.us
Fri Mar 7 09:03:47 CST 2008
Thanks A.D. this information is good to have
Maybe we can have this posted in some format on the DB website for easy
reference
**************************************************
* Patricia O'Connor
* Information Technology Specialist 3 (Programming)
* OTDA - BDMA
* (W) mailto:Patricia.O'Connor at otda.state.ny.us
* (w) mailto:aa1160 at nysemail.state.ny.us
**************************************************
>
--------------------------------------------------------
This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
-----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 03: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
>
>