Using the '.Value' Property

[Stang70Fastback]

Question guys: When is it appropriate to use the '.Value' property in your code? I'm OCD about keeping code as neat as possible, and I started wondering if I was doing things properly. For example, when referring not to a control, but a field in a linked table, which is the "correct" form to use? (Both work!)

Me.ModifiedTimestamp.Value = Now()

If Me.ModifiedTimestamp.Value = XYZ Then

or

Me.ModifiedTimestamp = Now()

If Me.ModifiedTimestamp = XYZ Then

There are lots of instances where I am either calling a value, or setting a value, and in both cases, up until now I was using the '.Value' property, but I'm starting to wonder if that is unnecessary. If you just reference the field, does Access automatically know you're referring to its property? When WOULD you use .Value, and when wouldn't you? Or should you always use it for good measure? Someone school me!

Thanks!

 

[CJ_London]

there is no need at anytime (that I can think of) to use the .value of a control since it is the default property of the control.

It is also not always necessary to use the me. prefix either since me is the default collection within a form or report - only when you have the same name in a different collection or are referring to another element of me - e.g. me.recordset

so

ModifiedTimestamp = Now()

is really all you need

 

[Stang70Fastback]

Oh wow. That's neat to know. Never even thought to eliminate the 'Me.' Though I do like that 'Me.' sets off IntelliSense which helps me ensure I'm typing the correct things.

To clarify. I have "ModifiedTimestamp" as a column in many, many tables, but I can just use the name without the 'Me.' because it will always refer to the one the form is linked to unless I specify otherwise?

 

[JHB]

I never use it!
Maybe not necessary to use Me. as CD_London writes, but if you use Me. then you always know it is not a variable. And this could give some problem in error finding if Option Explicit Statement is not set.
In the sample CD_London shows, you are not sure if it is a control or a variable the value is assigned to.

 

[Stang70Fastback]

Sounds good. I'll stick with Me. for the time being, but quit using the .Value property like a n00b. Thanks guys!

 

[CJ_London]

just to continue.... there is always the dot v bang debate per this link

http://bytes.com/topic/access/insights/620587-control-object-reference-me

 

[The_Doc_Man]

There is one and only one time that I have ever needed to know anything about the property called .Value - and that one time is to know when the control doesn't have a value property. The issue is that a label doesn't have a .Value but a text box DOES have .Value, so your problem isn't actually the value - but knowing what can and can't be done to a control because it does or doesn't have a value.

This sounds trivial but when you are writing code that does an enumeration of the collection of all controls on a form, some of them will have values and some will not. Some will have captions (labels, e.g.) and some will not. Some will be visible or invisible and some will not (because some controls use .Transparent rather than .Visible to determine if you can see them.)

So you need to know ahead of time about your controls OR you need to write something that asks the question "Does this control have this property?" - and .Value is one of the properties that isn't always there, so needs to be considered specially.

You might need to know how Access uses the property, though. For instance, if you have .Value (say, on a text box), you might or might not be able to know that the control is "dirty" because if it is an unbound control, it has no .OldValue against which to compare for being dirty. Therefore, if you wanted to remember that you changed the value of the control but it was unbound, you need to do special programming.

You also could run into issues with other options of the control that determine whether or not it has a .Value. For instance, a list box with Multiselect enabled does not have a value. (It has SEVERAL selected values.) But a list box with Multiselect turned off completely WILL have a value once a selection is made. Combo boxes have values in the same way, though there your issue is that any multi-column box can choose which column is used for the value.

I guess my point here is that .Value is very important to know about - but not that often so important as to actually name it as a property in a value assignment or value reference context. As CJ and JHB point out, there are many points of confusion about how you use it. (For example, the "bang" vs. "dot" reference mentioned by CJ is moot for something that has no .Value property.) I hope this helps you get some perspective on the uses, abuses, and misuses of .Value as a property.

 

[pbaldy]

Like others, I don't add the .Value, since it's the default. I do use Me, both to get the intellisense and I like to know at a glance whether I'm referring to a variable or form control.

 

[spikepl]

There is an instance where the .Value is useful/usable and its absence can yield and error: when you assign values directly from fields in recordset to some of the various bits and pieces of an outlook email - especially a hyperlink address to an outlook attachment, as far as I recall.

 

[Stang70Fastback]

Thanks for all the help guys. I did end up removing the .Value property from all of my code. I did, however, discover one instance where I did need to keep it. Setting a TempVar to the value of a control, I have to use the .Value property, or it tells me "you cannot store a CONTROL in a TempVar." Other than that, it works fine!

I have another, kinda-sorta-but-not-really related question that I'll ask here in the hopes that I don't have to start another thread:

Me.LastNameTXT = xyz

OR

Me.LastName = xyz

Which is more proper? The former means I am assigning the value to the TEXT BOX, which should then obviously fill in the underlying table field. Or should I use the latter, which directly fills the underlying table field, which should cause the text box to display it. Is one method preferred over the other?

As context, someone is selecting an item from a multi-column dropdown, which then populates the other fields with the values in the various columns. The full code looks like this:

Private Sub BadgeCOMBO_AfterUpdate()

'* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
'* TRIGGER: Operator Badge field is changed.                                             *
'*                                                                                       *
'* ACTION: Updates the First Name, Last Name, Location, and Seniority Date fields with   *
'*         the associated information.                                                   *
'* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

On Error GoTo ErrHandler

    Me.LastNameTXT = Me.BadgeCOMBO.Column(1)
    Me.FirstNameTXT = Me.BadgeCOMBO.Column(2)
    Me.SeniorityTXT = Me.BadgeCOMBO.Column(3)
    Me.LocationTXT = Me.BadgeCOMBO.Column(4)

Exit Sub

ErrHandler:
    LogTheError Err.Number, Err.Description, "ACCIDENT - BadgeCOMBO_AfterUpdate"
    
End Sub

 

[pbaldy]

I can't speak to proper, but I use the text box.

 

[CJ_London]

naming conventions is a matter of personal choice. Personally, I name all controls the same as the field they bound to, and if unbound I prefix with txt, cbo, lst, btn etc