Cannot assign a value (1 Viewer)

Gasman

Enthusiastic Amateur
Local time
Today, 15:45
Joined
Sep 21, 2011
Messages
14,057
I meant a routine to rename the controls on the report the same as I did with the form, though perhaps not as critical as forms, as I do not manipulate data that much in reports.
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 11:45
Joined
Oct 17, 2012
Messages
3,276
Fair enough, but yeah, you should be consistent through the app.
 

Mark_

Longboard on the internet
Local time
Today, 08:45
Joined
Sep 12, 2017
Messages
2,111
I disagree with Mark on control naming 100%.

You see, I go the other way around. If I can't tell from the name what a control is supposed to contain, then the name sucks and needs to be changed. However, it's just as important to know what kind of control you're working with.

I indicate the control type with the prefix, because that will tell me what special properties they have that others might not, such as Text for textboxes, RowSource for listboxes, etc. I took those prefixes straight from the Access Developer's Handbook:

*txt for textboxes
*cbo for comboboxes
*lst for listboxes
*cmd for command buttons
*etc

That makes it easy for me to know while coding both what kind of control it is and what data it contains. Examples are cboRecoveryIDNum, txtDOB, cmdQuit, and lstScreenName. Each makes it explicitly clear both what kind of control it is (and thus which properties are available), what data it contains (if any), and what general type that data is.

Very odd... I point out that you should have a naming convention.
You disagree.
You then list a naming convention.

Very strange.... I guess you may have missed the first half of the statement.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 10:45
Joined
Feb 28, 2001
Messages
27,005
alanm2007, just for the record:

it turns out that I need to turn off the reference library for calendar control as it's no longer valid in 2016!
What that has to do with that bit of coding (which has no date reference in it) is beyond me!

The reason is that when Access is looking for something that it doesn't have intrinsically as part of the language or one of your own functions or variables, it goes through the reference list in order. But... if in the process of that search it finds a FAILURE in the search, it stops looking. So if that calendar control library wasn't the last thing in the list, anything defined later in the list cannot be found because that search stops at the first match or first error. Failure to find something isn't an error... failure to find something and reaching a stopping point in the list IS an error.

That is what that control had to do with anything.
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 11:45
Joined
Oct 17, 2012
Messages
3,276
Very odd... I point out that you should have a naming convention.
You disagree.
You then list a naming convention.

Very strange.... I guess you may have missed the first half of the statement.

I'm not sure how someone could get 'Do not use a naming convention' out of 'I disagree with Mark's reasoning about which prefixes to use', but you somehow managed to pull it off. For now, I'll go with 'completely misread the post' rather than 'deliberate obtuseness.'

I didn't object to a naming convention - I disagreed that Gasman's naming convention is bad, and I think your insistence that you prefix controls based on data type rather than control type (based on your comments in posts 12 and 16) is terrible advice, both because it violates accepted practice for use of Hungarian notation, and because it provides zero data not already available in a well-selected name. All the convention you described does is make your control names harder to read without providing a single bit of useful data.

Naming a control strAddress provides literally zero additional info over naming it Address, while txtAddress tells me that in addition to being an Address field, the control itself is a text box.
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 10:45
Joined
Feb 28, 2001
Messages
27,005
I use the txt, cbo, lst, ckb, cmd, rct prefixes for one very important reason. When the code reaches critical mass (as in, my head would explode if I tried to memorize all of it), I need the prefixes to tell what kind of control it is so I can remember what methods I can apply to it and what properties I get tweak. The data-type convention might work for recordset or dynamic query operations but in a class module, I need to know what I can do to something, not what is actually in it.
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 11:45
Joined
Oct 17, 2012
Messages
3,276
I use the txt, cbo, lst, ckb, cmd, rct prefixes for one very important reason. When the code reaches critical mass (as in, my head would explode if I tried to memorize all of it), I need the prefixes to tell what kind of control it is so I can remember what methods I can apply to it and what properties I get tweak. The data-type convention might work for recordset or dynamic query operations but in a class module, I need to know what I can do to something, not what is actually in it.

Yep, that's basically a better way of explaining my own reasoning too. I can determine the data type from the name, but it's vital I know the CONTROL type, since different types will have different properties and methods.
 

Mark_

Longboard on the internet
Local time
Today, 08:45
Joined
Sep 12, 2017
Messages
2,111
Doc,

Do you use a special prefix if you've done something to the control, such as special validation for that form or restrict a textbox for numeric only?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 10:45
Joined
Feb 28, 2001
Messages
27,005
I don't recall ever doing that.

More specifically, in the big projects, I pre-defined everything using template forms that contained all of the command buttons and common error handler code for the form basic events. There was a cmdXXX for things like Create, Remove, Commit, Cancel, Close, etc. and EVERY ONE OF THEM was customized after the fact anyway. Ditto, the form's Open, Load, Current, BeforeUpdate, Close, Unload, etc.

I would copy a template to a new name and then go in to implement the .Recordsource and controls. I even had some code I copied for the "vanilla" .GotFocus and .LostFocus routines. There were SO many control customizations that it was almost pointless to use a special label. But using the templates worked out OK. I found that from 40% to in some cases 60% of the layout work was handled by the template.
 

Users who are viewing this thread

Top Bottom