No need for table fields on a form

[DickyP]

But what if "controlname" refers to a non-existing control? I would only find out at runtime that it does not exist.

True but that is based on the bizarre suggestion you are going to use it for real without testing. If you do that you deserve everything you get.

 

[Isaac]

I kinda like the Me.controlname better - However, I like Dicky's method when it comes to Recordset fields.

 

[DickyP]

I actually generally use the Me.ControlName syntax - I merely offered the Me.controls("Name") as a possible choice, where necessary.

 

[Galaxiom]

But if they DO have corresponding controls and the control name is the same as the field name then Me.mumblefratz could actually be an ambiguous reference. This is why we often suggest that you should take great care to name a control and its corresponding field differently.

No ambiguity. The Controls collection is prioritised.
I use the same names and unambiguous references to make it absolutely clear in situations where I need to refer to both.

Me!Recordset.Fields.somename
Me!Controls.somename

 

[DickyP]

To me using proper naming conventions is as important as proper code formatting and proper relational data design: if you've got them you are 99% of the way to successful development.

I'm still using the Lezinski naming conventions I started using with Access2 and VB 3.

 

[The_Doc_Man]

No ambiguity. The Controls collection is prioritised.

Slight disagreement. We have seen issues on this forum in the past where the control/field ambiguity reared its ugly head. For folks who are on older versions of Access, this COULD be an issue. However, I wouldn't doubt for a minute that MSFT quietly did something about it to impose that prioritization in newer versions.

 

[MajP]

We have seen issues on this forum in the past where the control/field ambiguity reared its ugly head.

I would be interested in you or someone else citing an example, because that is untrue as far as the application. There may be "confusion" but Access is not "ambiguous" . Any issue would be purely a user issue and have nothing to do with Access. The user might be confused what they are doing but I I can ensure you it Is is not a problem with older versions of Access (at least for that last 25 years). The behavior always prioritized the control.

A user can confuse themselves and maybe think there is an Access issue.
1. You could have a control named Status that is unbound or not bound to the field called Status. That I have seen done where they renamed a control or mistakenly changed what field bound to.
2. Queries reference controls not fields so if you remove the control it does not work
3. You think you are updating the field but you are updating the control
4. Value in field can be different from value in the control until the record is saved.

Do not get me wrong, there are very good reasons to rename any control you use in code or a query. But not because there is or was "ambiguity".
I asked Chat to double check me on this.

From Access 2.0 → Access 97 → 2000 → 2003 → 2007 → 2010 → 2016 → 2019 → 365:
The rule has always been:
1. Control names
2. Field names in the form’s recordset
3. Properties/methods
So if a control and a field share the same name, Access will always resolve that name to the control first.
This is not a bug — it’s the design.

 

[DickyP]

As almost an aside the is probably no technical ambiguity -see above - but, however, there is mental ambiguity to the user in " what a I referring to this this time?"

 

[The_Doc_Man]

The user might be confused what they are doing

That, in and of itself, is a problem. If it confuses a user, it is a problem because it induces mistakes.

I'll have to try and find what the problem was, but I am absolutely certain that this topic has come up before, and I've been on the form for 25+ years. My memory isn't good enough to find it instantly, because it wasn't recent. But it was real.

 

[RaptorRaptur]

Are you saying there are cases where even using bang notation will fail without a control on the form? I understand there are cases where compile time Dot notation will not work without a control on a form, but the run time bang always seems to works without a control far as I know. If so can you explain a way to recreate a case where even bang will not work? I have seen cases where for some reason dot will not work, but if I add it to the form, save it, and then delete it, it works. In those cases I assumed it was some kind of bug and the fields were not added to the controls collection as "accessfield" controls. Adding then deleting seems to force it to work.

What is a "bang" in this context?

 

[The_Doc_Man]

What is a "bang" in this context?

"Bang" is the Exclamation Point, which allows you to search-by-name for a particular property. There is more to it than that. See this linked article.

Bang Vs Dot, Me, and Default Properties

This is a cleaned up version of a long thread with several sidebar conversations originally located at the link at the bottom of this thread. There is a lot of confusion about the use of Me. or Me! and Bang vs Dot in general. A lot of the discussion on the Internet is wrong or incomplete. The...

www.access-programmers.co.uk

Me.x and Me!x are ways to reference object properties among other things, and they both have their proper uses. I recommend you look at MajP's excellent summary of the differences between them.

 

[Isaac]

I recommend you look at MajP's excellent summary of the differences between them.

Or just never use !

 

[MajP]

Or just never use !

You cannot say never, since there are plenty of cases where you have to use !
1. Anything handled by the expression engine. Queries, Object properties, Conditional Formatting, etc.
2. Although rare, bang may be required for a dynamic recordsource. If you add the recordsource of a form or report at runtime then those fields do not exist as properties of the form. You can not use dot because your form/report will not compile.

 

[Isaac]

You cannot say never, since there are plenty of cases where you have to use !
1. Anything handled by the expression engine. Queries, Object properties, Conditional Formatting, etc.
2. Although rare, bang may be required for a dynamic recordsource. If you add the recordsource of a form or report at runtime then those fields do not exist as properties of the form. You can not use dot because your form/report will not compile.

i probably shoudda said prefer . rather than !