Is the Me. syntax required in form vba when referring to controls? (1 Viewer)

[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.

 

[Pat Hartman]

Let us not forget the copious comments that bear no resemblance to what the code is currently doing?

There is a middle ground. I don't comment obvious code. I comment complex code in general, not line by line . I comment WHY I chose to do something a particular way. WHY am I using a temp table rather than an array? WHY am i looping backward rather than forward. So design decisions are more likely to be commented rather than actual lines of code. Why is the code ensuring that no more than three items get added to the child table? I can see that it is limiting the child records to THREE. What I'm going t want to know next year is WHY. Sometimes I include user names in the comments. Sue said they have never had more than 3 instances and she's the one who wants the limit. That way your successor knows how to proceed if someone tries to enter four and can't.

What do you do with removed code? If I'm testing methods and don't know if I will have to go back to the original version, I comment it out and indent it. At the end, if I go with the replacement, I delete the original. If I feel that the original code might have a future use, I add it to a collection module and document why I'm keeping it.

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.

 

[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?

 

[Pat Hartman]

Gasman,
For me, it is better to actually remove code to a common database if I think it could be useful in a different situation. Sometimes I leave old code in place and commented out longer if I think I might need it the way it was originally written in a different place. Once I "reuse" it, I delete it. Old code just clutters the mind. Deciding what actually needs to be done is usually the difficult part of developing. Once I know what I want to do, writing the code to do it becomes trivial. Sometimes I need to do some thinking on how to code something but usually it just flows off the fingers A lot of stuff is personal style. I am far, far more likely to avoid silly coding errors in the initial draft than I am when I have to go back and modify existing code. Which is the reason why when I read books for my friend the author and my other friend the publisher, I to "last" read only. I'm just no good a second time through. My eyes glaze over.

I have dozens of design patterns in my head. Some of them I generalize and save to minimize tedious typing but ONLY if I can do it and mark SUBSTITUTION areas where the code must be customized. I make sure that the code will not compile cleanly until all the missing parts are filled in. Trying to find all the places that need changing is what causes latent bugs.

For example, I always use the same variable names for recordset, database, tabledef, querydef unless I need multiple objects in the same procedure open at the same time so I can easily keep a generalized recordset read or update loop. These mini-procs are only a few lines of code but it keeps me from making stupid errors or forgetting the error trapping that I generally use.

Access gives us a great framework because it does so much for us. When I was writing COBOL, coding was much more tedious (the smallest programs easily ran 500-1000 lines of code) so I used to keep more "pattern" code. i.e. 2-file match, 3-file match, report with 1 break level. report with 2 break levels, etc. Basic Transaction logic for add/change/delete.

 

[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