Bang vs. Dot - final answer

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in message
news:BZ********************@comcast.com...

I once did all my control references with the bang (!) operator. All my
controls were referenced as Me!txtInput, etc.

I have now discovered that doing this loses much more than Intellisense.

1. Compile does not pick up missing controls, i.e., if I have a reference to Me!btnEdit, and remove that button from my form, Compile will not show a
warning. It *will* show a warning if I have referenced my control as
Me.btnEdit.

2. Compile will not flag certain syntax errors - for instance, mistakenly
typing Me!btnEdit.SetFocus = True

Reason enough, I think, to always use the dot operator, even if it is not
'correct'.

--
Darryl Kerkeslager

Good points.

I have used only the dot for many years.

Darryl Kerkeslager wrote:

Reason enough, I think, to always use the dot operator, even if it is not
'correct'.

I'd be totally lost without my dot. It's one hell of a lot better than
PL/SQL or any other programming or developing language with no
intellisense (masochism), let me tell you.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

On Fri, 30 Sep 2005 07:48:49 -0400, "Darryl Kerkeslager"
<ke*********@comcast.net> wrote:

I once did all my control references with the bang (!) operator. All my
controls were referenced as Me!txtInput, etc.

I have now discovered that doing this loses much more than Intellisense.

1. Compile does not pick up missing controls, i.e., if I have a reference to
Me!btnEdit, and remove that button from my form, Compile will not show a
warning. It *will* show a warning if I have referenced my control as
Me.btnEdit.

2. Compile will not flag certain syntax errors - for instance, mistakenly
typing Me!btnEdit.SetFocus = True

Reason enough, I think, to always use the dot operator, even if it is not
'correct'.

Everything you say is true, and it's not enough.

The problem is that Access is just plain less reliable when you use a dot
reference for controls. I have about 10 times as much project corruption
using dot references as bang references, and the kinds of corruption that can
occur using the dot references can be really nasty including problems that
actually corrupt the linked back-end database when entering data through the
form, and problems that prevent opening the form in design view at all, so the
form must be recreated or re-imported from an old copy to get working again.

Steve Jorgensen wrote:

The problem is that Access is just plain less reliable when you use a dot
reference for controls. I have about 10 times as much project corruption
using dot references as bang references, and the kinds of corruption that can
occur using the dot references can be really nasty including problems that
actually corrupt the linked back-end database when entering data through the
form, and problems that prevent opening the form in design view at all, so the
form must be recreated or re-imported from an old copy to get working again.

For the last several years I have always used the dot and never the
bang. During that time I have not experienced the corruption you
describe.

On 30 Sep 2005 06:48:10 -0700, "lylefair" <ly******@yahoo.ca> wrote:

Steve Jorgensen wrote:

The problem is that Access is just plain less reliable when you use a dot
reference for controls. I have about 10 times as much project corruption
using dot references as bang references, and the kinds of corruption that can
occur using the dot references can be really nasty including problems that
actually corrupt the linked back-end database when entering data through the
form, and problems that prevent opening the form in design view at all, so the
form must be recreated or re-imported from an old copy to get working again.

For the last several years I have always used the dot and never the
bang. During that time I have not experienced the corruption you
describe.

Apparently, YMMV on this issue. Personally - I've had the problem with
multiple clients including some who had the problem before calling me in, some
cases while I was doing development enhancements to existing projects, and
some cases with new projects I was creating for clients from scratch.

Steve Jorgensen wrote:

On 30 Sep 2005 06:48:10 -0700, "lylefair" <ly******@yahoo.ca> wrote: Apparently, YMMV on this issue. Personally - I've had the problem with
multiple clients including some who had the problem before calling me in, some
cases while I was doing development enhancements to existing projects, and
some cases with new projects I was creating for clients from scratch.

Your post left me puzzled. Why would our experiences be so dissimilar?
Perhaps, it is because I seldom or never use the default properties for
objects like controls and fields.

For example, I write "rcs.Fields("LastName").Value = "Smith"
and "Me.LastName.Value="Smith"
rather than
"rcs.Fields("LastName") = "Smith"
and "Me.LastName="Smith"

I am aware that this may be slower, but I doubt that it is noticeably
slower. I am not suggesting that it should be anyone's preferred coding
style, except for me.

But it may prevent Access/VBA's confusing an object and its properties,
sonething that, I suppose, could cause corruption.

Of course, using the bang, would also prevent this
confusion->corruption.

lylefair wrote:
<snip>

For example, I write "rcs.Fields("LastName").Value = "Smith"
and "Me.LastName.Value="Smith"
rather than
"rcs.Fields("LastName") = "Smith"
and "Me.LastName="Smith"

I am aware that this may be slower, but I doubt that it is noticeably
slower.

I would have thought that using .Value would be (maginally) faster since
it doesn't have to figure out what the default property is before using
it. With any hardware built in the last 10 years, you would likely not
be able to even measure the difference in speed without iterating it
thousands of times.

--
Bri

"lylefair" <ly******@yahoo.ca> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Steve Jorgensen wrote:

On 30 Sep 2005 06:48:10 -0700, "lylefair" <ly******@yahoo.ca> wrote:

Apparently, YMMV on this issue. Personally - I've had the problem with
multiple clients including some who had the problem before calling me in, some cases while I was doing development enhancements to existing projects, and some cases with new projects I was creating for clients from scratch.

Your post left me puzzled. Why would our experiences be so dissimilar?
Perhaps, it is because I seldom or never use the default properties for
objects like controls and fields.

For example, I write "rcs.Fields("LastName").Value = "Smith"
and "Me.LastName.Value="Smith"
rather than
"rcs.Fields("LastName") = "Smith"
and "Me.LastName="Smith"

I am aware that this may be slower, but I doubt that it is noticeably
slower. I am not suggesting that it should be anyone's preferred coding
style, except for me.

But it may prevent Access/VBA's confusing an object and its properties,
sonething that, I suppose, could cause corruption.

Of course, using the bang, would also prevent this
confusion->corruption.

I have been using the dot notation for several years for all of the reasons
mentioned. I do, however, frequently use default properties. I haven't
experienced the sort of corruption that Steve described. I am quite
concerned about the prospect of running into such problems down the road.
Does anyone know if Microsoft has ever documented any preference for one
practice versus the other?

Off topic - I think using the default properties is probably "lazy" coding.
I regret not getting in the habit a long time ago of using explicit notation
for properties. I rather wish there was a way in Access to turn that off.
(my 2 cents worth)

Randy Harris wrote:

I have been using the dot notation for several years for all of the
reasons mentioned. I do, however, frequently use default properties.
I haven't experienced the sort of corruption that Steve described. I
am quite concerned about the prospect of running into such problems
down the road. Does anyone know if Microsoft has ever documented any
preference for one practice versus the other? [snip]

I have occassionally seen files get corrupted and one consequence of being
corrupted was that a lot of dot references suddenly didn't work (compile
error) and changing them to bangs would allow the project to compile.

I certainly never considered that the dot notations were the *reason* for
the corruption though. Only that they were affected by it.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in message
news:BZ********************@comcast.com...

1. Compile does not pick up missing controls, i.e., if I have a reference
to Me!btnEdit, and remove that button from my form, Compile will not show
a warning. It *will* show a warning if I have referenced my control as
Me.btnEdit.
An excellent reason to use the .dot. However, this is a double edged sword.
What happens if you change the reocrdsouce of a form, and then some of the
fields are NOT available.

me!SpecialID
me.SpeicalID

If you CHANGE the reocrdsouce of a form in code, then we can NOT compile, or
resolve the 2nd one (since, we can't know if there will in fact be a
SpecialID until AFTER we set the sql for the form). What this means is that
you must:

a) place a control on the form so that me.SpecialID will ALWAYS work
b) or start using the bang notation!

So, for fields like "id", and many other fields that you will NOT WANT to
place on the form, then you need to use the ! notation. (otherwise your code
will fail if you change the forms recordsouce).

So, while you gain in compile time checking, you loose the ability to
reference fields in the reocdset when you use dot (or, you are forced to
pile up a bunch of controls in the corner of the screen that only serve to
allow the "dot" notation to work). I can't tell you the number of times I
seen a access application with a WHOLE BUNCH of controls piled up in the
corner for JUST the reasons to use fields in the reocrdsouce. All of those
controls that are NOT being used for editing were ONLY there to serve to use
the "dot" notation. So, why pile up a bunch of controls that never get used
so you can use the 'dot' notation?

So, in place of have to put a whole bunch of un-used controls on the form,
why not use ! notation? (again, stress we are taking about when you change a
forms record source..but I find this happens more and more as my ms-access
skills improve).

For this reason, I have found the following trade off:

For things like "ID", and accessing fields of the reocrdsouce that will NOT
be on the form, or are NOT required to be on the screen, I now use the !
bang notation. Again, this rule is especially valuable if you have any code
that changes the reocrdsouce of a form.

2. Compile will not flag certain syntax errors - for instance, mistakenly
typing Me!btnEdit.SetFocus = True

Reason enough, I think, to always use the dot operator, even if it is not
'correct'.

Again, the above assumes you got a control called btnEdit. Since you ARE
setting the focus to a control, then you MOST certainly want to use "dot".
Again, in this example if you have a un-bound control called btnEdit, then
Me!btnEdit.SetFocus will NOT WORK!!! Again, in this case, it is clear that
the ! bang notation looks to the reocxreset, and then figures out that you
go a control with the same name. So, really, the rule should be that you
use 'dot' to refer to a control. The above example is bad, because it will
ONLY work if btnEdit is a BOUND control. What do you do for un-bound
controls? (! bang simply does not even work).

So, if you plan to use features of that control, (such as setting focus)
then of course you would use the ".dot". There is no final rule here, but
you are accessing, and setting focus to a control, and that requires you use
"dot". As mentioned, the ! notation will not even work for un-bound
controls, so it makes little sense to confuse the issue here.

So, for the sake of clarity, why adopt a rule where you use the 'dot'
notation when you NEED to use the actual control, and when you do NOT use
the actual control, then use the bang notion. For example

msgbox "company name is = " & me!CompnayName

If I go and delete the company name control on the form, the above code will
CONTINUE to operate. In other words, the above code will continue to
function if I delete some controls on the form. However, if your code RELIES
ON controls that MUST be on the form, then we should use the 'dot' notation,
as then deleting the control on the screen will be caught by the compiler
for you. Makes sense to me!! And, note the reverse:

if you did not need the controls, then if you used the ! bang notation and
delete the control on the screen, then your code will NOT fail!

So, if the above code is to RELY on the FACT of a complayName control on the
form, then I would use "dot". If the code dies NOT need to rely on the
control, then use bang.

Simply put, you as a developer can make a decision here on which one to use,
and that decision will make your resulting code more reliably, and will not
fail if you delete control. And, if done right, if you do delete a control,
then the compile will catch it in code that DOES requite the control.

So, don't just pick one blindly over the other. Pick the right notation that
will catch the right errors in your code!!
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

See my other post as to "when" or "why" the "dot" notation fails.

(it fails when you change the record source of a form, and do NOT have the
control of the same name on the form)

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Albert D. Kallal wrote:

See my other post as to "when" or "why" the "dot" notation fails.

(it fails when you change the record source of a form, and do NOT
have the control of the same name on the form)

Yes, but it also fails when the file gets corrupted. I have seen where the
bang won't compile on forms that haven't been touched (design wise) in years
and where there is never any manipulation of the RecordSource.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Well.... this is all very interesting. I've been developing in Access
since ver 2.0 came out. I have developed numerous applications for
numerous situations and businesses. Every book and every example I've
ever read refers to controls with the " ! " and their properties with
the " . ". This is the way I have always done it and not once has it
caused me a problem.

To me, .... Me!btnEdit refers to a control. Me.btnEdit refers to a
property of the active Object (Form, etc) and there just ain't no
property such as that.

What can I say? I know... I ain't changing my ways.

SilvrT wrote:

Well.... this is all very interesting. I've been developing in Access
since ver 2.0 came out. I have developed numerous applications for
numerous situations and businesses. Every book and every example I've
ever read refers to controls with the " ! " and their properties with
the " . ". This is the way I have always done it and not once has it
caused me a problem.

To me, .... Me!btnEdit refers to a control. Me.btnEdit refers to
a property of the active Object (Form, etc) and there just ain't no
property such as that.

Except that there is : )

Access exposes all controls on forms and reports as properties of the parent
container.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

"Albert D. Kallal" <ka****@msn.com> wrote

If you CHANGE the reocrdsouce of a form in code, then we can NOT compile,
or resolve the 2nd one (since, we can't know if there will in fact be a
SpecialID until AFTER we set the sql for the form). What this means is
that you must:

a) place a control on the form so that me.SpecialID will ALWAYS
work
b) or start using the bang notation!

So, for fields like "id", and many other fields that you will NOT WANT to
place on the form, then you need to use the ! notation. (otherwise your
code will fail if you change the forms recordsouce).
To reference fields, rather than controls, I have always used notation like:

Me("obligation_id") = rs.Fields("obligation_id")

Perhaps this is why I do not have this issue?
Again, the above assumes you got a control called btnEdit. Since you ARE
setting the focus to a control, then you MOST certainly want to use "dot".
Again, in this example if you have a un-bound control called btnEdit, then
Me!btnEdit.SetFocus will NOT WORK!!! Again, in this case, it is clear that
the ! bang notation looks to the reocxreset, and then figures out that you
go a control with the same name. So, really, the rule should be that you
use 'dot' to refer to a control. The above example is bad, because it will
ONLY work if btnEdit is a BOUND control. What do you do for un-bound
controls? (! bang simply does not even work). So, if you plan to use features of that control, (such as setting focus)
then of course you would use the ".dot". There is no final rule here, but
you are accessing, and setting focus to a control, and that requires you
use "dot". As mentioned, the ! notation will not even work for un-bound
controls, so it makes little sense to confuse the issue here.
Not sure what the disconnect is here. I use all sorts of command buttons
which are unbound, and they have always functioned perfectly using bang
notation:

Me!btnEdit.SetFocus
Me!btnNew.Enabled = True

etc
If I go and delete the company name control on the form, the above code
will CONTINUE to operate. In other words, the above code will continue to
function if I delete some controls on the form. However, if your code
RELIES ON controls that MUST be on the form, then we should use the 'dot'
notation, as then deleting the control on the screen will be caught by the
compiler for you. Makes sense to me!! And, note the reverse:
I understand your point full well, but disagree. For instance, I had a
button that allowed users to go to a quick lookup of agency information,
which appearred on several forms. Eventually, I concluded that it was more
confusing to users than helpful, and eliminated it. I quickly deleted all
on_click events, but forgot to delete places where I had enabled\disabled
it. Since I used the bang operator,

Me!btnGo.enabled = False

my code compiled, and everything ran smoothly. Great, according to what you
have. But, it is not great - had I used the dot operator, the compiler would
have flagged the missing control, and I would have removed a few lines of
excess (Access?) code - and still, it would compile.

However, let's look at another situation. I have Me!frmTerms, a frame of
radio buttons. Eventually, I decide that I don't have room on my form for
the frame and radio buttons, even though they made the choices more clear,
and I must change the structure to a combo box. I change the name to
Me!cboTerms, but really, most of the coding is identical, and I quickly make
a few changes, thinking I changed all the references. My code compiles all
right - *but it doesn't work* - because in one obscure place, I referenced
the value of Me!frmTerms, and didn't do a global replace.

If Me!frmTerms = f then Exit Sub

no longer functions, and I go merrily about missing it, thinking everything
is okay.

If Me.frmTerms = f then Exit Sub

would have raised a compiler error.

I, personally, would much rather be informed of the problem, rather than
code happily compiling and me not knowing that a real error exists.

So, don't just pick one blindly over the other. Pick the right notation
that will catch the right errors in your code!!

Exactly.

--
Darryl Kerkeslager

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:BZ********************@comcast.com:

I once did all my control references with the bang (!) operator.
All my controls were referenced as Me!txtInput, etc.

I have now discovered that doing this loses much more than
Intellisense.

1. Compile does not pick up missing controls, i.e., if I have a
reference to Me!btnEdit, and remove that button from my form,
Compile will not show a warning. It *will* show a warning if I
have referenced my control as Me.btnEdit.
If your control names use mixed case, you still get the benefit of
capitalization in code. If you type me!btnedit and it doesn't
convert to Me!btnEdit, you know you've got a typo (or a collision in
the namespace -- much less likely).
2. Compile will not flag certain syntax errors - for instance,
mistakenly typing Me!btnEdit.SetFocus = True

Reason enough, I think, to always use the dot operator, even if it
is not 'correct'.

Not reason enough for me.

There are certain kinds of errors and corruption tha result from
using the bang operator.

Also, you're depending for all those features on Access creating
implicit wrappers around all your controls. I don't like depending
on those kinds of complex implicit features.

Secondly, it violates the meaning of . and ! -- the former means
"method, property or member" while the latter means "member of
default collection." I think that distinction is useful, so that
your code clearly distinguishes the use of
methods/properties/members of the Me object from references to
controls or fields.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

From the Help file ----

Use the ! and . (dot) operators in expressions

You use the ! and .(dot) operators in an identifier to indicate the type of
item that immediately follows.
The ! operator indicates that what follows is a user-defined item (an
element of a collection). For example, use the ! operator to refer to an
open form, an open report, or a control on an open form or report.

The . (dot) operator usually indicates that what follows is an item defined
by Microsoft Access. For example, use the . (dot) operator to refer to a
property of a form, report, or control.
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications
re******@pcdatasheet.com
www.pcdatasheet.com

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in message
news:BZ********************@comcast.com...

I once did all my control references with the bang (!) operator. All my
controls were referenced as Me!txtInput, etc.

I have now discovered that doing this loses much more than Intellisense.

1. Compile does not pick up missing controls, i.e., if I have a reference
to Me!btnEdit, and remove that button from my form, Compile will not show
a warning. It *will* show a warning if I have referenced my control as
Me.btnEdit.

2. Compile will not flag certain syntax errors - for instance, mistakenly
typing Me!btnEdit.SetFocus = True

Reason enough, I think, to always use the dot operator, even if it is not
'correct'.

--
Darryl Kerkeslager

"Albert D. Kallal" <ka****@msn.com> wrote in
news:Exg%e.9405$oW2.6177@pd7tw1no:

the above assumes you got a control called btnEdit. Since you ARE
setting the focus to a control, then you MOST certainly want to
use "dot". Again, in this example if you have a un-bound control
called btnEdit, then Me!btnEdit.SetFocus will NOT WORK!!! Again,
in this case, it is clear that the ! bang notation looks to the
reocxreset, and then figures out that you go a control with the
same name. So, really, the rule should be that you use 'dot' to
refer to a control. The above example is bad, because it will ONLY
work if btnEdit is a BOUND control. What do you do for un-bound
controls? (! bang simply does not even work).

What in the *hell* are you talking about? The ! works just fine and
dandy for unbound controls.

It's the only way I ever refer to controls -- no dots in any of my
apps at all.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"Albert D. Kallal" <ka****@msn.com> wrote in
news:Exg%e.9405$oW2.6177@pd7tw1no:

So, if you plan to use features of that control, (such as setting
focus) then of course you would use the ".dot". There is no final
rule here, but you are accessing, and setting focus to a control,
and that requires you use "dot". As mentioned, the ! notation will
not even work for un-bound controls, so it makes little sense to
confuse the issue here.

To repeat:

The above final statement is JUST NOT TRUE.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"Albert D. Kallal" <ka****@msn.com> wrote in
news:Exg%e.9405$oW2.6177@pd7tw1no:

So, don't just pick one blindly over the other. Pick the right
notation that will catch the right errors in your code!!

I think that having a rule that depends on so many contingencies as
you've outlined will produce far less readable and maintainable
code. Someone reading the code is *not* going to be able to figure
out why you use one or the other.

You could have created this simple rule that would have solved the
problems you outlined, though:

Use ! for fields in the underlying recordsource.

Use . for controls on the form.

I don't do that, but it certainly works.

I don't find the compile-time checking you get with the . to be
worth the problems it raises. And I never us anything but ! for
references either to recordsource fields or controls on the form.

I think the implementation of the implicit wrapper functions in
A95/97 was a huge mistake.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"David W. Fenton" <dX********@bway.net.invalid> wrote

There are certain kinds of errors and corruption tha result from
using the bang operator.
I assume this is a typo - you don't meant that using the bang (!) can
*cause* corruption, do you?
Secondly, it violates the meaning of . and ! -- the former means
"method, property or member" while the latter means "member of
default collection." I think that distinction is useful, so that
your code clearly distinguishes the use of
methods/properties/members of the Me object from references to
controls or fields.

David,

I have wholeheartedly agreed with you on this for quite awhile - but I have
changed my mind.

While I see the benefits in making my code clear, and have faithfully used
the bang operator for controls up until now - if the ONLY benefit I get is
to make my code a smidgen clearer, and I am giving up instead the benefit of
compile-time error checking - that, it seems, is not a good trade-off.
--
Darryl Kerkeslager

PC Datasheet wrote:

From the Help file ----

Use the ! and . (dot) operators in expressions

You use the ! and .(dot) operators in an identifier to indicate the type of
item that immediately follows.
The ! operator indicates that what follows is a user-defined item (an
element of a collection). For example, use the ! operator to refer to an
open form, an open report, or a control on an open form or report.

The . (dot) operator usually indicates that what follows is an item defined
by Microsoft Access. For example, use the . (dot) operator to refer to a
property of a form, report, or control.
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications
re******@pcdatasheet.com
www.pcdatasheet.com

I'm sure that's what Microsoft intended. That's basically the way I
use them. But I think Albert and others are right about taking
advantage of the situation in ways Microsoft never intended (as long as
the NG style police don't try to force any of the unintended uses on
us). As far as unintended uses go I like to see people doing things
for a reason. Of course, my reason for not adopting this good advice
is that the blind choice is a quick one. I've not encountered the
problems others have seen - yet. But if I begin to see problems I
might change my mind.

James A. Fortune

Exactly what I stated .... except in different words.

Per Albert D. Kallal:

An excellent reason to use the .dot. However, this is a double edged sword.
What happens if you change the reocrdsouce of a form, and then some of the
fields are NOT available.

me!SpecialID
me.SpeicalID

Maybe I'm just too anal about it, but I would not name a field on a form
'SpecialID'.

Presumably, that field is bound to an input column named 'SpecialID' and I'd
name the field on the form 'txtSpecialID' or 'cboSpecialID' or something like
that.

Can't remember when/where the distinction between a control name and it's
..ControlSource becomes critical, but I got burned a few times early-on and have
adhered to separate, prefixed names for controls ever since.
--
PeteCresswell

Per David W. Fenton:

Use ! for fields in the underlying recordsource.

Use . for controls on the form.

I don't do that, but it certainly works.

I use ! for anything that doesn't trigger intellisense - including fields in
recordsets and controls on other forms (as in forms!frmHome!txtWhatever).
--
PeteCresswell

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:_M********************@comcast.com:

"David W. Fenton" <dX********@bway.net.invalid> wrote

There are certain kinds of errors and corruption tha result from
using the bang operator.

I assume this is a typo - you don't meant that using the bang (!)
can *cause* corruption, do you?

Yes. I need to fire my typist, who seems to have a habit of typing
exactly the opposite of what I mean! :) It's the . that can lead to
the corruption that Steve reports.

I encountered a situation in an app created by someone else where it
was badly broken and I went through and converted all the .
operators to !, and was able to fix the project after that. I didn't
do it because I attributed the corruption to the . operator -- I did
it to bring the code up to my standards.

Secondly, it violates the meaning of . and ! -- the former means
"method, property or member" while the latter means "member of
default collection." I think that distinction is useful, so that
your code clearly distinguishes the use of
methods/properties/members of the Me object from references to
controls or fields.

I have wholeheartedly agreed with you on this for quite awhile -
but I have changed my mind.

While I see the benefits in making my code clear, and have
faithfully used the bang operator for controls up until now - if
the ONLY benefit I get is to make my code a smidgen clearer, and I
am giving up instead the benefit of compile-time error checking -
that, it seems, is not a good trade-off.

I think the avoidance of corruption is a very good one.

I think avoiding depending on an implicitly-created wrapper over
which you have no control is a very good thing.

When it works, yes, it's helpful.

When it doesn't work, it's hellish.

And the alternative is hardly much of a hardship. The kinds of
problems the lack of compile-time checking of the ! can have on an
app is pretty minor, since at runtime it's going to show up. If you
do any testing at all, you're going to catch it. If you use mixed
case in your control names, you're going to get a certain amount of
feedback from the VBA compiler, in any event, as long as you type in
non-mixed case.

Try programming in something like PHP, where you don't get anything
but runtime errors and you come to appreciate what VBA offers, and
you tend to not miss something so minor as no compile-time checking
of control references.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"(PeteCresswell)" <a@b.c.invalid.USA> wrote in
news:rs********************************@4ax.com:

Per David W. Fenton:

Use ! for fields in the underlying recordsource.

Use . for controls on the form.

I don't do that, but it certainly works.

I use ! for anything that doesn't trigger intellisense - including
fields in recordsets and controls on other forms (as in
forms!frmHome!txtWhatever).

You can get Intellisense by hitting Ctrl-Spacebar after typing the
bang. It's not the exact same list as you get with the . but it's
sufficient to get save a lot of typing after you've typed a couple
of characters.

From the time that I found out about Ctrl-Spacebar, I've considered
the Intellisense argument of no consequence at all. Before that, it
loomed large.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:i9****************@newssvr11.news.prodigy.com :

Albert D. Kallal wrote:

See my other post as to "when" or "why" the "dot" notation fails.

(it fails when you change the record source of a form, and do NOT
have the control of the same name on the form)

Yes, but it also fails when the file gets corrupted. I have seen
where the bang won't compile on forms that haven't been touched
(design wise) in years and where there is never any manipulation
of the RecordSource.

The bang never fails to compile for control and field references in
forms.

Did you, like me, type the opposite of what you meant?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:Xz***************@newssvr11.news.prodigy.com:

SilvrT wrote:

Well.... this is all very interesting. I've been developing in
Access since ver 2.0 came out. I have developed numerous
applications for numerous situations and businesses. Every book
and every example I've ever read refers to controls with the " !
" and their properties with the " . ". This is the way I have
always done it and not once has it caused me a problem.

To me, .... Me!btnEdit refers to a control. Me.btnEdit
refers to a property of the active Object (Form, etc) and there
just ain't no property such as that.

Except that there is : )

Access exposes all controls on forms and reports as properties of
the parent container.

Which makes absolutely no sense, since they are not properties or
metehods of the parent object.

They are, arguably, members in a sense, but that's not usually what
we mean by that.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:Xo********************@comcast.com:

I, personally, would much rather be informed of the problem,
rather than code happily compiling and me not knowing that a real
error exists.

Search and replace is such a hard concept?

Really, I don't use the dot operator and I'm not shipping code out
to my clients with those kinds of runtime errors. When I change the
name of a control or delete it, it is just part of the process to
search the module for any references to that control so that I can
clean them up. If I did it with . I'd be visiting them anyway in
order to get it to compile again.

I don't see the benefit as worth the corruption risks and the lack
of clarity in the code since it's no hardship to understand the
implications of deleting/renaming and fix it when you do it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"(PeteCresswell)" <a@b.c.invalid.USA> wrote in
news:4m********************************@4ax.com:

Can't remember when/where the distinction between a control name
and it's .ControlSource becomes critical, but I got burned a few
times early-on and have adhered to separate, prefixed names for
controls ever since.

I only give the control a distinct name when I see that it needs to
be referred to in code, or needs to have an event. That's the first
point at which you need to distinguish the control from the
underlying field.

There is one case where you have to put a control on a form to work
with the data in the underlying field, and that is when referring to
a field in a parent form from a child form. If you do it without
creating a control (hidden or visible) that is bound to the
underlying field, you can get the runtime error 2426, which is
fatal.

The same code works just fine and dandy in A97 -- this problem was
introduced in A2K, and it's a severe one.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

David W. Fenton wrote:

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:i9****************@newssvr11.news.prodigy.com :

Albert D. Kallal wrote:

See my other post as to "when" or "why" the "dot" notation fails.

(it fails when you change the record source of a form, and do NOT
have the control of the same name on the form)

Yes, but it also fails when the file gets corrupted. I have seen
where the bang won't compile on forms that haven't been touched
(design wise) in years and where there is never any manipulation
of the RecordSource.

The bang never fails to compile for control and field references in
forms.

Did you, like me, type the opposite of what you meant?

Yep :-)

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

"David W. Fenton" <dX********@bway.net.invalid> wrote

It's the . that can lead to
the corruption that Steve reports.
I think the avoidance of corruption is a very good one.

Obviously you will never make it in politics.

But what is the corruption? I don't see how exactly it can create
corruption.

--
Darryl Kerkeslager

Darryl Kerkeslager wrote:

"David W. Fenton" <dX********@bway.net.invalid> wrote

It's the . that can lead to
the corruption that Steve reports.

I think the avoidance of corruption is a very good one.

Obviously you will never make it in politics.

But what is the corruption? I don't see how exactly it can create
corruption.

I would add that the few times I have seen "the corruption" it was while
developing in the file. I have never seen a user's functioning file suddenly
have this form of corruption.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

SilvrT wrote:

Well.... this is all very interesting. I've been developing in Access
since ver 2.0 came out. I have developed numerous applications for
numerous situations and businesses. Every book and every example I've
ever read refers to controls with the " ! " and their properties with
the " . ". This is the way I have always done it and not once has it
caused me a problem.

To me, .... Me!btnEdit refers to a control. Me.btnEdit refers to a
property of the active Object (Form, etc) and there just ain't no
property such as that.

If controls are not properties of the form they are on then how do you
explain:

Call PassedControl (me.txtFirstName)

Sub PassedControl(ctl As Access.TextBox)
MsgBox ctl.value
End Sub

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:K6****************@newssvr11.news.prodigy.com :

Darryl Kerkeslager wrote:

"David W. Fenton" <dX********@bway.net.invalid> wrote

> It's the . that can lead to
> the corruption that Steve reports.

> I think the avoidance of corruption is a very good one.

Obviously you will never make it in politics.

But what is the corruption? I don't see how exactly it can
create corruption.

I would add that the few times I have seen "the corruption" it was
while developing in the file. I have never seen a user's
functioning file suddenly have this form of corruption.

Um, why would that be relevant, since the decision to use . or ! is
a developer issue -- end users never know which one you use.

It's entirely a development issue, a way to avoid problems. So the
fact that once you've successfully skirted the danger of corruption
during development you can relax is not really commonsensical -- you
don't know when you're going to hit the corruption DURING
DEVELOPMENT, so in my opinion, it's best to avoid the technique that
can cause the corruption.

And what you're giving up is something that, I would argue, is not
such a great advantage as all that. The compile-time checking is
providing by implicit wrappers that you cannot control and that's a
black-box layer that I'd rather not rely on.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:jY**************@newssvr27.news.prodigy.net:

David W. Fenton wrote:

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:i9****************@newssvr11.news.prodigy.com :

> Albert D. Kallal wrote:
> > See my other post as to "when" or "why" the "dot" notation
> > fails.
> >
> > (it fails when you change the record source of a form, and do
> > NOT have the control of the same name on the form)
>
> Yes, but it also fails when the file gets corrupted. I have
> seen where the bang won't compile on forms that haven't been
> touched (design wise) in years and where there is never any
> manipulation of the RecordSource.

The bang never fails to compile for control and field references
in forms.

Did you, like me, type the opposite of what you meant?

Yep :-)

No wonder these discussions keep coming up over and over again! The
archives are filled with posts by people who muddy the waters by
typing exactly the opposite of what they mean! :)

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

David W. Fenton wrote:

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:K6****************@newssvr11.news.prodigy.com :

Darryl Kerkeslager wrote:

"David W. Fenton" <dX********@bway.net.invalid> wrote
> It's the . that can lead to
> the corruption that Steve reports.

> I think the avoidance of corruption is a very good one.

Obviously you will never make it in politics.

But what is the corruption? I don't see how exactly it can
create corruption.

I would add that the few times I have seen "the corruption" it was
while developing in the file. I have never seen a user's
functioning file suddenly have this form of corruption.

Um, why would that be relevant, since the decision to use . or ! is
a developer issue -- end users never know which one you use.

It's entirely a development issue, a way to avoid problems. So the
fact that once you've successfully skirted the danger of corruption
during development you can relax is not really commonsensical -- you
don't know when you're going to hit the corruption DURING
DEVELOPMENT, so in my opinion, it's best to avoid the technique that
can cause the corruption.

And what you're giving up is something that, I would argue, is not
such a great advantage as all that. The compile-time checking is
providing by implicit wrappers that you cannot control and that's a
black-box layer that I'd rather not rely on.

Again though, I agree that I have seen a type of corruption that manifests
itself by having DOT references malfunction. I don't know that this
automatically means that the use of the DOT notation is what *causes* the
corruption. Perhaps it is merely the "canary in the coal mine". Is there an
authoritative reference that says the corruption is actually caused by the use
of the DOT notation?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

On Sat, 01 Oct 2005 23:36:30 GMT, "Rick Brandt" <ri*********@hotmail.com>
wrote:

David W. Fenton wrote:

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:K6****************@newssvr11.news.prodigy.com :

> Darryl Kerkeslager wrote:
> > "David W. Fenton" <dX********@bway.net.invalid> wrote
> > > It's the . that can lead to
> > > the corruption that Steve reports.
> >
> > > I think the avoidance of corruption is a very good one.
> >
> > Obviously you will never make it in politics.
> >
> > But what is the corruption? I don't see how exactly it can
> > create corruption.
>
> I would add that the few times I have seen "the corruption" it was
> while developing in the file. I have never seen a user's
> functioning file suddenly have this form of corruption.

Um, why would that be relevant, since the decision to use . or ! is
a developer issue -- end users never know which one you use.

It's entirely a development issue, a way to avoid problems. So the
fact that once you've successfully skirted the danger of corruption
during development you can relax is not really commonsensical -- you
don't know when you're going to hit the corruption DURING
DEVELOPMENT, so in my opinion, it's best to avoid the technique that
can cause the corruption.

And what you're giving up is something that, I would argue, is not
such a great advantage as all that. The compile-time checking is
providing by implicit wrappers that you cannot control and that's a
black-box layer that I'd rather not rely on.

Again though, I agree that I have seen a type of corruption that manifests
itself by having DOT references malfunction. I don't know that this
automatically means that the use of the DOT notation is what *causes* the
corruption. Perhaps it is merely the "canary in the coal mine". Is there an
authoritative reference that says the corruption is actually caused by the use
of the DOT notation?

There's no way to know for certain, of course, but the nature and symptoms of
the corruptions that occur lead me to think it's a cause, not just a syptom.
In one case, for instance, the problem occurred after renaming a number of
controls on a form. That form's code was the part of the project that was
then too damaged to recover.

Off the main subject, but continuing to ramble...

If I tried to open the form in design view, Access would crash. If I imported
the form into another project, I could open the form in design view just once,
then it would crash Access. The trick that finally worked for recovering the
form was to import the form into another project, copy the code text out using
the clipboard (Access would crash when closing the form now, but the code was
copied out), import the form into yet another project, change its "Has Module"
property to "No", save that, import the no-module version of the form it into
yet another new project, and paste the code text back into its module.

> Use ! for fields in the underlying recordsource.

Use . for controls on the form.

I don't do that, but it certainly works.
I do that.

We started doing that because of the behaviour of
VSS/SaveAsText/LoadFromText.

When a form is saved/loaded using SaveAsText, as
Visual Source Safe does, the matching form properties
for unbound fields are not created.

We don't use VSS any more (it was too slow and
flaky), but our standard remained: . for controls,
! for unbound fields. As a result, we now occasionally
use unbound fields on late bound forms, where before
we would have created a bound control.

(david)
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142... "Albert D. Kallal" <ka****@msn.com> wrote in
news:Exg%e.9405$oW2.6177@pd7tw1no:

So, don't just pick one blindly over the other. Pick the right
notation that will catch the right errors in your code!!

I think that having a rule that depends on so many contingencies as
you've outlined will produce far less readable and maintainable
code. Someone reading the code is *not* going to be able to figure
out why you use one or the other.

You could have created this simple rule that would have solved the
problems you outlined, though:

Use ! for fields in the underlying recordsource.

Use . for controls on the form.

I don't do that, but it certainly works.

I don't find the compile-time checking you get with the . to be
worth the problems it raises. And I never us anything but ! for
references either to recordsource fields or controls on the form.

I think the implementation of the implicit wrapper functions in
A95/97 was a huge mistake.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Most of the examples you see published are conceptually
generic: they translate to VB and VBS and ASP. (This is
universally true of Microsoft examples).

If your coding includes significant amounts of VBS
or ASP, then you will want to stick with the generic
coding style.

If your coding is almost all in Access VBA, you
may want to use the features provided by that
special environment.

(david)

"SilvrT" <rl*****@telus.net> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Well.... this is all very interesting. I've been developing in Access
since ver 2.0 came out. I have developed numerous applications for
numerous situations and businesses. Every book and every example I've
ever read refers to controls with the " ! " and their properties with
the " . ". This is the way I have always done it and not once has it
caused me a problem.

To me, .... Me!btnEdit refers to a control. Me.btnEdit refers to a
property of the active Object (Form, etc) and there just ain't no
property such as that.

What can I say? I know... I ain't changing my ways.

When A2K first came out, I got code corruption all the
time. We had to give up using MDE libraries for the first
year, just because we couldn't get the applications to
consistently compile correctly when using MDE libraries.

And Error handlers didn't work correctly: we couldn't
depend on exceptions bubbling up to the top level
handler.

Exceptions of any kind frequently caused GPF's (with
possible code corruption).

Unbound forms with incorrectly referenced field properties
caused exceptions, which then caused GPF's, which caused
possible code corruption.

But this was general problem with A2K instability.

To a certain extent, I've learned to live with it: we
still get GPF's instead of VBA exceptions sometimes,
but in general I code to avoid exceptions now: for example,
I'll loop through a control collection to see if a control
exists, rather than trying to catch an exception if it
doesn't exist.

On the other hand, I don't have trouble with MDE code
libraries, and, when not GPF'ing, exceptions do bubble
up to the first active exception handler.

So I use ! for unbound fields, because in certain rare
cases (VSS, unbound forms), unbound fields may cause an
exception to be raised (which may cause a GPF).

But I do use . (dot) for all other form properties. I've
never had a missing form property except when referring to
unbound fields. If anything, I'm more worried about
referring to a missing member of a collection, because
(1) it's not caught by compilation, and (2) I know that
a missing collection member will cause a runtime exception,
which may cause a GPF.
(david)

"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:1j********************************@4ax.com...

On Sat, 01 Oct 2005 23:36:30 GMT, "Rick Brandt" <ri*********@hotmail.com>
wrote:

David W. Fenton wrote:

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:K6****************@newssvr11.news.prodigy.com :

> Darryl Kerkeslager wrote:
> > "David W. Fenton" <dX********@bway.net.invalid> wrote
> > > It's the . that can lead to
> > > the corruption that Steve reports.
> >
> > > I think the avoidance of corruption is a very good one.
> >
> > Obviously you will never make it in politics.
> >
> > But what is the corruption? I don't see how exactly it can
> > create corruption.
>
> I would add that the few times I have seen "the corruption" it was
> while developing in the file. I have never seen a user's
> functioning file suddenly have this form of corruption.

Um, why would that be relevant, since the decision to use . or ! is
a developer issue -- end users never know which one you use.

It's entirely a development issue, a way to avoid problems. So the
fact that once you've successfully skirted the danger of corruption
during development you can relax is not really commonsensical -- you
don't know when you're going to hit the corruption DURING
DEVELOPMENT, so in my opinion, it's best to avoid the technique that
can cause the corruption.

And what you're giving up is something that, I would argue, is not
such a great advantage as all that. The compile-time checking is
providing by implicit wrappers that you cannot control and that's a
black-box layer that I'd rather not rely on.

Again though, I agree that I have seen a type of corruption that manifests
itself by having DOT references malfunction. I don't know that this
automatically means that the use of the DOT notation is what *causes* the
corruption. Perhaps it is merely the "canary in the coal mine". Is there
an
authoritative reference that says the corruption is actually caused by the
use
of the DOT notation?

There's no way to know for certain, of course, but the nature and symptoms
of
the corruptions that occur lead me to think it's a cause, not just a
syptom.
In one case, for instance, the problem occurred after renaming a number of
controls on a form. That form's code was the part of the project that was
then too damaged to recover.

Off the main subject, but continuing to ramble...

If I tried to open the form in design view, Access would crash. If I
imported
the form into another project, I could open the form in design view just
once,
then it would crash Access. The trick that finally worked for recovering
the
form was to import the form into another project, copy the code text out
using
the clipboard (Access would crash when closing the form now, but the code
was
copied out), import the form into yet another project, change its "Has
Module"
property to "No", save that, import the no-module version of the form it
into
yet another new project, and paste the code text back into its module.

I would just like to say that I have seen some of my Access projects
get corrupted and close up, WITHOUT EVER INDICATING WHY. At least now,
I have some insight into what might be causing the issue. Thanks.