Hi,

Ryan's example shows you how you would set variables within your mainform to store this information for you, and then you would need to be calling the GetContextVariable function, knowing some control within that form, like when you're calling it from a button handler or something like that.

If that is not acceptable, that function should be easily converted to use VWGContext.Current.MainForm to get to the mainform and provide the same functionality as Ryan is suggesting.

Palli

Hi Ryan,

Where there is a problem, there is always a way... you're welcome :-)

Palli

Hi Danny,

I will try to explain....

First, static variables are global and are shared between every instance of the application. Module in VB.NET is static, and variables declared in there are shared between all users of your application. I think it's safe to say that static variables are living in the Application scope, in that sense.

Of the 3 reimaining storage scopes, the Cookie scope should be easily understood, which leaves us with the Session and Context storage scopes. There is a difference between browsers and even browser versions on how they treat this, but let's take Firefox as an example. Firefox runs all it's tabs, and all it's windows within one single process on your PC. Even if you open a new window in FF, you are running in the same process on your client PC. This is a little different from some version of IE for instance, where a new process is started on your client if you open a new IE window, but if you open a new tab, you'll use the same process.

The info about the browsers is relevant when you open a session to your web application. In FF (which uses the same process for all) will use the same session to connect to your app in all it's tabs and all it's windows.

Now to the VWGContext. Context in VWG is defined as a mainform and what's being done in there. If you access your app via two ways, http://yourapp/Form1.wgx and http://yourapp/Form2.wgx, you will have one Context when you access via Form1 and another context when accessing via Form2 .... but both will have the same Session (within FF or new tab in IE or IE version that doesn't create new process).

As for storing your variables in a safe "local" place, in an application that has 2 mainforms, and therefor has 2 VWGContexts you have three options:

1. If you want both the forms to access the same variables, you can use the Session context. Think of for instance how you set the IsLoggedOn flag via Context.Session.IsLoggedOn = True. This goes for both forms, meaning if you log into one, you are logged into the other. But then you must of course store your user credentials in a session variables also, so you can retrieve them when you start the second form.
2. If you want each of your MainForms (Form1 and Form2 above) to have it's own sets of variables, you can declare your variables locally within the form. They will then be local to the instance of your form.
3. Again, same as in number 2 above, you can save your variables to the VWGContext, which gives you one set of variables for each of your forms too.

So this all depends on your requirements.

My usual approach is that I use Session variables to store the name of the logged on user, but try to keep the info stored there as small as possible. Setting Context.Session.IsLoggedOn = True and then Context.Session("UserName") = "loggedinuser" should be enough in most cases.

Then in my mainforms I keep a variable local to the form, with additional information required for info about the user. I most often have it in special class and read extra info in from a Database when I know the user is logged on.I then create an instance of that class in the Form's load event, and store the instance in a variable local to the form.

This approace is just one of many possibilities, but it makes those information local to each VWGContext (that is MainForm) I have in my app.

Hope this gives you some understanding and helps a little.

Feel free to ask if you need any more explainations.

Palli