How to use tempvars

[jackie77]

Hi all

does anyone know how to use a tempvar in the following line

Forms!ColdTemperatures![TempVars("Button1")].ForeColor = vbRed

what im doing is on close of a form I want to change the colour of a button on another open form (the name of the button is held in the tempvar)

But i cant get it to work

any suggestions would be great?

cheers
jackie

 

[KenHigg]

a - where do you put the line of code you posted?
b - maybe you need to refresh the form where where the control is located

 

[jackie77]

Hi KenHig

Thanks for the reply

From my form "ColdTemperatures" I click a button and the tempvar is added and the form "AddTemp" opens I then add data to this form and when I click a button on this form it closes and the form "ColdTemperaturs" requerys and its at this point I want the button on "coldTempatures" to change color

this is the code on the button on the "AddTemp" form I have

bSaveClicked = True    
DoCmd.Close
    Forms!ColdTemperatures.Requery
    Forms!ColdTemperatures!ColdTempSubform.Requery
    Forms!ColdTemperatures![TempVars("Button1")].ForeColor = vbRed

 

[KenHigg]

This is a stab in the dark but I would think the requery would go at the bottom...

 

[jackie77]

Hi Ken

I have tried it before and after the requery but still I get the error 2465
"Can't find Field TempVar (Button1)

I have tested the tempvar on opening the "AddTemp" form just in case it didnt add properly but the tempvar is fine

I have also double checked the name of the button (whos font colour I am trying to change) matches the value held in the tempvar and that all looks fine

Now sure where Im going wrong

Jackie :banghead:

 

[MarkK]

When you use the bang (!) character to reference the member of a collection, you must use the actual name of the member. If you want to evaluate something, use parenthesis, like . . .

    Forms!ColdTemperatures(TempVars("Button1")).ForeColor = vbRed

. . . which is really just shorthand for . . .

    Forms!ColdTemperatures.Controls(TempVars("Button1")).ForeColor = vbRed

. . . but I would try and avoid TempVars for this too. This value is set by this same form isn't it? TempVars make sense if you "push" a value to the TempVar, and then some other object "pulls" it from the TempVar later. In your case, it appears that you "push" the value to the TempVar, and then you push it again to another form. The only advantage of using a TempVar is defeated if you never "pull" from it. Your original object should keep that value and just push it directly to the other form.

 

[jackie77]

Hi

Thanks for the reply guys, Mark cheers that works - but I get what your saying about the Tempvar so I will redo and push it over from the form

I appricate you taking the time to explain it to me -means I will know it next time

Thanks Again

 

[Galaxiom]

The main purpose of TempVars is their ability to be used in queries. Using them in code is one hundred percent pointless.

Personally I never use them and doubt that I ever will.

The oddest thing about their name is that or all "variables" they are the least temporary.

 

[DevTycoon]

Could someone address the consequences of using [TempVars]![tmpYourTempVariableHere] with multiple users for client only applications? I did not see that addressed here in this thread.

 

[MarkK]

address the consequences

What consequences do you mean?

 

[BlueIshDan]

How about just an explanation on why you shouldn't have to use tempvars within your code.

 

[KenHigg]

Hi KenHig

Thanks for the reply

From my form "ColdTemperatures" I click a button and the tempvar is added and the form "AddTemp" opens I then add data to this form and when I click a button on this form it closes and the form "ColdTemperaturs" requerys and its at this point I want the button on "coldTempatures" to change color

this is the code on the button on the "AddTemp" form I have

bSaveClicked = True    
DoCmd.Close
    Forms!ColdTemperatures.Requery
    Forms!ColdTemperatures!ColdTempSubform.Requery
    Forms!ColdTemperatures![TempVars("Button1")].ForeColor = vbRed

I'm not 100% sure but it seems you have made an erroneous leap in understanding how tempvars work. The main error seems in thinking the tempvar has attributes like forecolor. I would like to stop at this point and ask if you have seen this usage somewhere in case it is my understanding that is incorrect - ?

 

[Galaxiom]

How about just an explanation on why you shouldn't have to use tempvars within your code.

The functionality of TempVars lies between VBA variables and values stored in tables. They are more persistent than VBA variables but are not retained when the project is closed like values in a table.

TempVars is a Collection with a scope that covers the whole project. As such they can be referenced not only in code but in queries too.

Good programming practice avoids excessively scoping variables. As such, if the value is not required in a query there is no good reason to use a TempVar to store it.

Some developer like them because, unlike ordinary variables, they persist after a reset of the VBA. However, properly constructed code does not get reset. Moreover, their persistence means they need to be actively cleared out (or the project closed and reopened) to return the project to the initial state. Unexpected TempVars left behind from previous runs can potentially cause very strange behaviours.

They have a serious limitation as a variable in that they cannot store objects or arrays, only strings or numbers. For example in the OP's situation they are trying to use it to store the name of a control. A VBA variable could store a pointer to the actual control.

 

[DevTycoon]

The functionality of TempVars lies between VBA variables and values stored in tables. They are more persistent than VBA variables but are not retained when the project is closed like values in a table.

TempVars is a Collection with a scope that covers the whole project. As such they can be referenced not only in code but in queries too.

Good programming practice avoids excessively scoping variables. As such, if the value is not required in a query there is no good reason to use a TempVar to store it.

Some developer like them because, unlike ordinary variables, they persist after a reset of the VBA. However, properly constructed code does not get reset. Moreover, their persistence means they need to be actively cleared out (or the project closed and reopened) to return the project to the initial state. Unexpected TempVars left behind from previous runs can potentially cause very strange behaviours.

They have a serious limitation as a variable in that they cannot store objects or arrays, only strings or numbers. For example in the OP's situation they are trying to use it to store the name of a control. A VBA variable could store a pointer to the actual control.

I asked about the consequences and appreciate all of your insight! I should further clarify my question by asking if temp variables can cause issues on a database that is not split. I am trying to sell the split database concept to my supervisor but that also means I will need more time for development. At this moment, I am out of time for development and have avoided all use of temp vars because I am scared that multiple users on a single database file may cause functionality issues down the line. I really only tried to use them to pass a primary key between forms.

What is your perspective on the use of these temp variable on a "non-split" database with multiple users

 

[Galaxiom]

What is your perspective on the use of these temp variable on a "non-split" database with multiple users

Unsplit database with multiple users is a disaster waiting to happen whether you use TempVars or not.

I really only tried to use them to pass a primary key between forms.

There are many ways to do this. One is to use an ordinary public variable (in the Declarations section of a Standard Module). But then this variable has the unnecessarily wide scope of the Project (except the queries).

I prefer using the OpenArgs argument of the OpenForm method.

The details really depend on exactly what you are doing.

 

[KenHigg]

Back to the original issue - Did you ever get the color of the button to change. Seems you don't need to use a variable at all if the form with the button is already open...

 

[MarkK]

I am scared that multiple users on a single database file may cause functionality issues down the line.

It sounds like you don't totally get the architecture of a split database. In a split database there is a single back end (BE) data file on a network server, and there are multiple front end (FE) program files, one for each user, which independently connect to the data file. Since each user has his/her own FE program file, there is no risk of conflict between TempVar values because TempVars maximum scope is the application, and each user is running his/her own instance.

 

[KenHigg]

I prefer using the OpenArgs argument of the OpenForm method.

Based on his original code it appeared as though the form was already open - ?

 

[Galaxiom]

Based on his original code it appeared as though the form was already open - ?

As I said earlier, "The details really depend on exactly what you are doing." There are so many different ways, each with their particular strengths.

With a form already open I might have used a custom Property to accept the value I wanted to pass. Or use a custom Property to point to a control on the original form that is to be used by the destination form to get the PK for new records.

 

[KenHigg]

I must be missing something, just turn the darn thing red...