By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,209 Members | 1,100 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,209 IT Pros & Developers. It's quick & easy.

Microsoft's choice to default form textbox names to related table field names - good or bad?

P: n/a
MLH
Generally, I do not monkey with renaming controls on forms
whose name, by default, matches the name of their related
table fields. But I noticed the following today

If IsNull(Me!VColor) Then
DoCmd.CancelEvent
SaveButtonClicked = False
MyString = "You must tell us the color of the vehicle."
MyString = MyString & "Please choose the vehicle color from "
MyString = MyString & "the drop-down box provided on form."
MsgBox MyString, vbExclamation, "Vehicle Color Required - "
Exit Sub
End If

This code has been in my app for 9-mos. "What's the point", you ask?
The point is this: The control's name is NOT VColor. Its a combo-box
control and its name is ColorChooserBox. The related table field name
is [VColor].

A line in there like this
Me!VColor.BackColor = 255
would-a-produced an error. I would-a-seen & fixed it.
But because Null is a perfectly acceptable value for the table field
value - I got no error. I would have appreciated one, however. The
result of this SNAFU is not monumental really. Because either of the
following in the immediate window yield the same result:

?forms!frmVehicleEntryForm!VColor
Azure
?forms!frmVehicleEntryForm!ColorChooserBox
Azure

But how do I knoiw that I won't be so lucky in another situation
that's similar - but slightly different. Is it possible, in A97, for
Access to use a different naming convention for controls on forms?
I would-a-been happier, I think, if Microsoft had defaulted names to
something like ctlVColor or comboxVColor or cboxVColor. I think I
would-a-been happier with cbox1, cbox2, cbox3... like they do with
command buttons.
Apr 6 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
MLH wrote:
Generally, I do not monkey with renaming controls on forms
whose name, by default, matches the name of their related
table fields.


<snip>

I didn't follow what you were trying to say in the rest of your post,
MLH, but the above definitely caught my eye.

I personally make it a habit to definitely rename bound controls to a
standard naming convention. Otherwise you end up with a lot of #Name!
type errors when trying to perform actions or procedures on controls. I
always advise newbies to do the same and tell them it's never good
practice to do what you describe above unless there is no coding
whatsoever connected with the form/report.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Apr 6 '06 #2

P: n/a
MLH
<snip>
I didn't follow what you were trying to say in the rest of your post,
MLH, but the above definitely caught my eye.

I personally make it a habit to definitely rename bound controls to a
standard naming convention. Otherwise you end up with a lot of #Name!
type errors when trying to perform actions or procedures on controls. I
always advise newbies to do the same and tell them it's never good
practice to do what you describe above unless there is no coding
whatsoever connected with the form/report.


I tend to agree with you. Would be nice if we could set a low-level
option specifying our desired control naming convention to A97.
Apr 7 '06 #3

P: n/a
MLH wrote:
I tend to agree with you. Would be nice if we could set a low-level
option specifying our desired control naming convention to A97.


Agreed. Or even if it just didn't name it the same as the blinking
controlsource!!! 8)
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Apr 7 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.