Assigning value to TempVar (1 Viewer)

[KitaYama]

I have a text box in a form. At any time I can use:

MyString = MyTextBox

Since .Value is the default property of a text box, it works and MyString will be equal to whatever I have in the text box.

But if I use :

TempVars("MyTempVar") = MyTextBox

I receive an error telling me I can not assign an object to a tempvar. I have to use :

TempVars("MyTempVar") = MyTextBox.Value

and it works.

Is there any reason why tempVar doesn't use the default property of objects?

 

[arnelgp]

it is a long time flaw (or is it?) with tempvars.
when you assign it (without using .Value) it tends to
assign the Object itself and not the value.

 

[GPGeorge]

it is a long time flaw (or is it?) with tempvars.
when you assign it (without using .Value) it tends to
assign the Object itself and not the value.

I'm not sure this is a flaw, in the sense that tempvars are different from other Access objects, but it is definitely an unexpected and undesirable feature.

 

[Isaac]

VBA afterupdate help

Hello, I currently creating a DB to sum fields and place them in a db field. Which is working kinda fine until.. Private Sub VIP_Pcs_AfterUpdate() Me.Total_Pcs.Value = Me.PcsTot Me.Tax_Amt.Value = Me.TaxSum Me.Bling_Total.Value = Me.BlgTot Me.Refresh End Sub I have 3 other afterupdate fields...

www.access-programmers.co.uk

 

[KitaYama]

VBA afterupdate help

Hello, I currently creating a DB to sum fields and place them in a db field. Which is working kinda fine until.. Private Sub VIP_Pcs_AfterUpdate() Me.Total_Pcs.Value = Me.PcsTot Me.Tax_Amt.Value = Me.TaxSum Me.Bling_Total.Value = Me.BlgTot Me.Refresh End Sub I have 3 other afterupdate fields...

www.access-programmers.co.uk

@Isaac I'm afraid I'm confused.
If I understand your post (suggested link), you're trying to tell me don't rely on default property and it's better to always include what property I'm pointing at (.value in this case).
While I understand your logic there, I think my question here is somewhat different. I was trying to understand why variables use the default property (.value) but tempVar doesn't. TempVar can not keep a reference to an object any way. I think it's normal that tempvars("mytemp")=myTextbox look at the .value property, because it can't be used to keep an object.

Thanks for taking your time and trying to help.

 

[Mike Krailo]

It's best not to overthink the TempVars behavior to mistake the referenced control as an object. It's just the way it is. Some programmers force the result into a string by concatenating a vbNullString to resulting contents of the control but I like using the value property instead.

TempVars("MyTempVar") = Me.MyTextBox & ""

 

[The_Doc_Man]

@KitaYama and others: The issue includes this fact - Microsoft doesn't give us insights into coding details. We don't know exactly how TempVars is implemented. From the on-line help files, a TempVars object is a member of a collection. This means that you aren't necessarily assigning a value to a variable. You are assigning it to a collection member. We know that VBA is context sensitive, but we usually assign values to variables or properties (which are merely variables associated with an object). This apparently isn't the same. I think we have to take the Zen approach and say "This is what it does. We can accept that and move on."

 

[KitaYama]

This means that you aren't necessarily assigning a value to a variable. You are assigning it to a collection member.

@The_Doc_Man Thanks for your insight.

The following works, even though I'm assigning it to a collection member.

    Dim PKs As New Collection

    PKs.Add MyTextbox, "test"
    Debug.Print PKs("test")

I'm assigning a textbox to a member of collection even though I didn't use .Value (Default property)
AND the value of the textbox is assigned to the collection. Not the object (textbox) itself.
So I think it's not because of tempVar is a member of collection.

 

[The_Doc_Man]

I'm assigning a textbox to a member of collection even though I didn't use .Value (Default property)

Yes, but you are assigning it to a generic collection. We don't know the data type of the TempVars collection, so despite both being part of a collection, it is an "apples to oranges" comparison.

In that syntax, MyTextbox (if it is, in fact, a textbox) could be added to your collection as an object but then the DEBUG.PRINT could be the thing that takes the .Value from the object. We couldn't tell from that test whether the object was copied to the collection. See if you can get a Debug.Print to show you PKs("test").Backcolor or some other similar property. If it doesn't error out then you inserted the whole object.

The first argument of collection.Add is an object, followed by the text key to identify the object for random access, followed by the "before" and "after" objects - i.e. provide ordering of insertion, threading the object into a linked list perhaps. Because collections do allow you to reference their members by index numbers.

 

[KitaYama]

We don't know the data type of the TempVars collection

I think it's the whole point.
Thanks for reminding me of that.