Cannot assign a value

[Gasman]

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]

Fair enough, but yeah, you should be consistent through the app.

 

[Mark_]

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.

 

[NauticalGent]

Opened a new thread in the WC regarding this: http://www.rustycans.com/HISTORY/oldfroth.html

 

[The_Doc_Man]

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]

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.

 

[The_Doc_Man]

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]

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_]

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]

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.