Is the Me. syntax required in form vba when referring to controls?

[cyberman55]

I just inherited another developer's database and noticed tons of code behind forms where he doesn't use me. to refer to the control, just its name. So, for example:

He uses statements such as txtAgentID= rather than me.txtAgentID when referring to a control called txtAgentID on the form with has the data source of AgentID.

Is this an acceptable way to do it? I'm inclined to add me. to these statements. Any ins-and-outs on this? I didn't even know it worked.

 

[Minty]

If there is a control and a field called the same it will all get a bit "interesting", I wouldn't like to bet which value was updated.

 

[Gasman]

I always used Me, but then I leave the controls textbox controls as a wizard names them, which is the same as the source field.?

That is not recommended by some experts. Even my typing is not bad enough to avoid typing Me. each time.

 

[theDBguy]

Hi. Just one person's humble opinion... I would only do it if I was bored.

PS. That is, if the database has been working fine for a long time. Cheers!

 

[missinglinq]

Also, when typing in

Me.txtAge

VBA's IntelliSense should finish it by popping up

Me.txtAgentID

If it doesn't...it means VBA can't find txtAgentID...isn't valid name...perhaps because it's misspelled! It's a good 'spell check,' if you will!

Linq ;0)>

 

[The_Doc_Man]

Here's the thing to consider: Access has all sorts of defaults. Inside a form's VBA code, "Me." is assumed, but as Linq points out, Intellisense doesn't make assumptions. If you fully qualify the item (e.g. adding the prefix "Me.") then Intellisense will look at what you started to type and give you the first matching item within the context of the prefix.

But as long as the references are unique? You don't need the Me. qualifier. HOWEVER, Gasman's warning IS appropriate. A form designed by a wizard uses the same name for the control on the form and for the field in the .Recordsource query. AND the field name IS visible from the form because it is also part of the form's .Recordset (obviously, for bound forms.)

 

[cyberman55]

Thanks, all - I too find intellisense useful and vaguely recall not having or using it, perhaps 23 years ago. And, yes, if the control is named the same as the source, it would be risky. I was told this developer started the project and then got buried so they hired me to finish it. It does work
'mostly' fine and the developer had good SQL skills and general techniques. But he put in no error trapping and uses some archaic language (at least to me) such as docmd.gotocontrol("txtcontrolname") rather than me.txtcontrolname.setfocus. But the strangest thing is he prefaces almost all chucks of code with a comment such as in every procedure ' Declare variables. I just can't figure the guy out.

 

[theDBguy]

Thanks, all - I too find intellisense useful and vaguely recall not having or using it, perhaps 23 years ago. And, yes, if the control is named the same as the source, it would be risky. I was told this developer started the project and then got buried so they hired me to finish it. It does work
'mostly' fine and the developer had good SQL skills and general techniques. But he put in no error trapping and uses some archaic language (at least to me) such as docmd.gotocontrol("txtcontrolname") rather than me.txtcontrolname.setfocus. But the strangest thing is he prefaces almost all chucks of code with a comment such as in every procedure ' Declare variables. I just can't figure the guy out.

There you go... I might spend more time adding error handlers than adding the Me keyword.

Personally speaking, of course... Cheers!

 

[cyberman55]

Error handling, er, YES. Always.

 

[The_Doc_Man]

But the strangest thing is he prefaces almost all chucks of code with a comment such as in every procedure ' Declare variables. I just can't figure the guy out.

Don't know what you are working on, but sounds like someone I might have trained. You NEVER EVER write code without copious comments, because you will one day come back to that code and scratch your head for while, asking yourself "WTF was I thinking?" Without seriously copious comments, you won't remember for ages. With them, you will remember in a matter of moments. I once had the nightmare of being given a code segment written in assembly language and had exactly one comment - the author's name. We needed to add a feature and I had never seen this code before. Took me two days to decipher the code but when I was finished, you could read what it said and know what it was doing.

Now, more specifically, a comment like "Declare variables" would have gotten a slap on the wrist from me because I would have said something like "Declare variables for geometric interpolation formula" (or whatever was appropriate.)

 

[Galaxiom]

Unqualified references will cause VBA to first look for variables by that name, then controls, then fields in the recordset.

 

[Galaxiom]

NEVER EVER write code without copious comments,

Excessive comments reduce readability. I've seen code where there are more lines of comment than code. Comments like "declare variables", "increment counter", "cleanup objects" where the action is inherently obvious from the code are particularly inane.

I would rather see a short explanation before each block of code where the purpose or methodology is not obvious.

 

[The_Doc_Man]

We actually DO agree at least partly on this, G. Comments like "increment counter" and "cleanup objects" would have gotten bad marks in my programming class. I would rather see no comments than to see nonsense or useless comments. And I agree that excessive comments reduce readability. However, "no comments at all" TOTALLY eliminates readability for any code longer than one screen-full. (I.e. not possible to see the whole routine on screen at once using scroll-bars.) So there has to be a happy medium. (Or at least a satisfied seer?)

As a side note, many moons ago (literally decades ago) I was the lead designer on a company project that reached several hundred thousand lines of assembly language coding. I had a program that pre-scanned things prior to placing them in the "official" code repository. It looked for things like not having a formal .TITLE declaration, which wouldn't stop anything but it WAS part of the company's "style guide." Also looked in the code for copyright declarations and company name as part of the comment header. Little things like that.

As a side result, this scanner told me how many comments were in the code, broken down as in-line comments and whole-line comments. Turns out that each of my coding staff members had a style that made it possible to know which one wrote the module without looking for a signature. I.e. on a line-by-line basis, Tom wrote 45% in-line and 10% whole-line comments, but Mike wrote 55% in-line and 14% whole-line comments. It was a characteristic with surprisingly small standard deviation.

 

[MajP]

. But the strangest thing is he prefaces almost all chucks of code with a comment such as in every procedure ' Declare variables.

Sometimes when you see " over commenting" the developer may have been using an add-in like MZ-Tools and just let it run for all procedures. This provides a "wizard" to add comment blocks throughout the code. There is a template and then it moves from procedure to procedure prompting for the descriptions to add.
If I click "add" it then it builds this block prompting for the Purpose and parameter purpose. All else it fills in automatically.

' ----------------------------------------------------------------
' Procedure Name: GetEmpName
' Purpose: Gets the Employee ID
' Procedure Kind: Function
' Procedure Access: Public
' Parameter EmpID (String): Pass the Employee ID in so you can look up related table fields.
' Return Type: String
' Author: MajP
' Date: 5/28/2021
' ----------------------------------------------------------------

It also can build all the error checking blocks, so maybe not.

 

[Cronk]

I also like the 'WHY' comments.

As to Sue type situations, I've had cases where there are multiple outcomes that need to be handled differently. Rather than ignoring an outcome that I'd been informed could not happen, is not to include that as a comment but action that outcome by popping up a message "Cronk was told by Sue this could not happen. Please contact Cronk to fix." My preverse nature I guess.

 

[CJ_London]

Haven’t read the whole thread but my style is to write the steps required as ‘step’ notes, then add the code, it helps me get loops in the right place

sometimes things don’t go to plan but at least I know what I’m expecting down the line

i don’t bother with notes such as ‘declare variables’ or ‘error handler’

 

[Gasman]

Pet peeve . Commented out dead code. This is a symptom of someone who doesn't know how to actually write code and who feels that a line of code written should be saved for posterity. This is just clutter and makes the real code harder to read.

That would be me. I tended to do that to see how I initially did it, and to refer to in case I needed to do something similar, and would not be able to use the latest code in that situation?

 

[NauticalGent]

Pet peeve . Commented out dead code. This is a symptom of someone who doesn't know how to actually write code and who feels that a line of code written should be saved for posterity. This is just clutter and makes the real code harder to read.

Ouch! Guilty as charged

 

[cyberman55]

Thanks to all for your comments about comments. I agree that it's stupid to comment on obvious stuff, which my previous coder did, and that it's smart to comment on the why(s), which wasn't done. What really confused me is that the guy had a good mastery of SQL, basic logic, etc. but didn't know enough to put in error trapping, and then he released it for use by a department of six people. They struggled with it and its crashes (opening up the code window) for two years before going on strike. It's just mysterious to me how this could have happened. I did note he used some archaic (to me) techniques such as docmd.gotocontrol "ccc" rather then me.controlname.setfocus. So I speculate he once know Access development fairly well but moved on to other things for a decade or two. And, not knowing the whole story, he may have intended to go back and add error code and someone blew the whistle and stopped development.

 

[Zedster]

I prefer to use me for all the reasons above + what I always do is use mixed case in object names e.g. txtDiscussions, then when I am coding I always enter me.txtdiscussions and let intellisense capitalise it for me. If I have a bad day and type me.textdiscussions or me.txtdiscussion I immediately know that I have got the object name wrong becuase it does not get capitalised.