Passing a variable from a click event

[Neuman]

I'm drawing a complete blank here. In Access 2003 I have an application consisting of tabs on a form. I need to set a variable based on which of two tabs has been selected. So if tab1 is selected, varx = 1. If tab2 is selected varx=0. I think I need to set varx in the tab1/tab2 click events but how do I pass the value of this variable on to all the other subs and functions that need to know whcih tab set the variable?

[GolferGuy]

I always have a hidden form open that is populated with fields that I will want to share between processes. This form is opened by the form that is the Main Menu for my app.

In your case, you could create this form, put a text box on the form, name it something like LastTabSelected. I happen to name my hidden form "frmUtility" because it is used throughout my app, therefore has a "utility" function. So, in order to set or read this variable, just refer to the text box on the hidden form. This would be the syntax for reading the value stored:
YourVariableName = Forms!frmUtility!LastTabSelected
This would be the syntax for storing the value:
Forms!frmUtility!LastTabSelected = 1 (from the event for Tab 1)

You don't need to worry about 1 user stepping on another while using this because each user gets their own copy of the Access database in their own computer. It's only the data in tables that is actually shared, not the data in forms.

[Tony Hine]

I would suggest the problem is more a case of what happens when another tab is selected, or the form is closed. This could make that logic you need to apply quite complicated, if you can it is far better to avoid storing such a variable.

[GolferGuy]

Neuman,
In case you have not found how to know within your program which tab was selected by the user, you need to use the tab control object, then the OnChange event for the tab control object. Here is the code I use:
MsgBox "Tab selected was: " & Me.MyTabControl.Value
If you want to shorten it to MyTabControl that works too. Of course, MyTabControl is the name of your tab control on your form.
If you try to use the OnClick event of the individual tabs, that event only fires when the body of the tab, not the tab itself with the tab name, is click on. So, the best way (in my humble optition) to think of a tab control is as an option box. And the individual tabs (where the name of the tab is) are just like the individual options within an option box. At least that thought has help me over the years as I have used the tab control.

Tony,
I don't understand your concern for NOT storing which tab was selected for later use with the application. Could you explain that a little more please?

[Neuman]

Thanks for the reply! We had thought about using a hidden control and you've just verified that it might work!. Thanks a lot.

[Tony Hine]

Tony,
I don't understand your concern for NOT storing which tab was selected for later use with the application. Could you explain that a little more please?

Certainly, --- It's considered poor practice to use global variables for storing things, and in my experience usually you can find a way of achieving your objective without resorting to using global variables for storing things in hidden forms and the like.

In this particular problem for instance, you do not need to store the condition that the control is in because you can access it from another form directly thus: MsgBox " >>> " & YourForm.YourTab.Value

[Tony Hine]

>>>The best way to think of a tab control is as an option box, and the individual tabs (where the name of the tab is) are just like the individual options within an option box<<<

BTW This makes a lot of sense to me, next time I am working with a tab control I will try thinking about it like this.

[GolferGuy]

Tony, Glad I could help with the understanding and working with tabs. I love them, as do my users, but they drove me "up a wall" when I first started using them. When I have more than 5 to 10 tabs, and therefore that many different forms to open all at once, I have gone to only 1 subform and all the tab control does is use that one subform control to put whatever form tab 5 requires. In order to keep a record of "where am I", I use my hidden form with global variable on it ALL the time. I guess I missed that lecture about global variables being a poor practice. I have used them in one form or another for over 30 years now and really don't know how I would get along without them. It seems to me that properties within a class could be used as a "global" variable, so why would those be OK, but variables stored on a "global" utility form would not be OK?

[Tony Hine]

>>>I guess I missed that lecture about global variables being a poor practice<<<

So did I! I have known for a long time it is considered poor practice, however I have had situations where it seems the only solution.

I can't remember whom I asked to explain to me why it was considered poor practice, I didn't really get an answer as to why, the answer was it is seldom necessary. And indeed as with many things in MS Access, there are usually several ways to achieve the same result, once you are in the habit of looking for a solution which avoids the use of global variables you can very often find it.

As to using a hidden form, I am making the assumption that the same idea, "avoid using global variables" would apply in this situation as well. (Does not mean that I am right!)

[GolferGuy]

Tony, thanks for the reply. I'm sure not saying I'm right, but I will say that I really do like my hidden form with it's global variables on it. I have as yet to see where or why it would be a poor practice. Nor have I ever had any form of an idea go through my head as to another way of doing this. For example, my longest running client and application has a system where the customer must be selected first, then the project, then the plan or job. This is if the tabs are used. A user can do a job search which then retrieve the project and customer IDs. But with no forms staying open except the one being displayed, getting to the customer number from the job number has to go through the project. It is sure a lot easier to just get the customer number from the hidden form with all the global variables on it.

[Tony Hine]

I did a quick search in the forum where I mainly post under the pseudonym "Uncle Gizmo" and found this thread which has some bearing:

The global variable is avoided by passing the variable directly to the form in question through a function and then storing it in the form as a private variable.

So in effect you are passing a variable via a function and storing it locally.