Search KB Filter article types
Storage Scopes
Categories: State Serialization, Session Serialization
Tags: Architects, Developers, Visual WebGui Pipeline, 1. Beginner, 2. Intermediate, 3. Advanced, Pre v6.3, v6.3, v6.4 and Later
Revision: 1
Posted: 22/July/2009
Updated: 04/Dec/2010
Status: Publish
Types: Article

Overview

Because of Visual WebGui's Server centric architecture and yet providing us with development environment that resembles the Windows Forms development environment, we tend to forget that in terms of variables (especially static variables), different rules apply in Visual WebGui from those in Windows Forms. On top of that, Visual WebGui is web oriented, builds on ASP.NET, and that introduces some additional means of storing (static) data, namely the four different storage scopes.

It is always good to remember that all variables you declare in your Visual WebGui application will be stored at the server. They may some have some UI representaton on the client or other type of connection to client components, but the variables you declare in your code and their contents are stored at the server, with the exception of the Cookie variables that are a special case.

Availability

Information in this article applies to all versions of Visual WebGui.

Storage ScopesLocal variables

Local variables, as long as they are not declared as static, behave exactly the same as they do in Windows Forms.

Variables declared local within a procedure, are local to that procedure, and fields or controls within a class (like controls on a form) are local to that class.

Static variables

Static variables (shared in VB.NET) are very different in Visual WebGui from how they act in Windows Forms. In Windows Forms your application will be running in a seperate process with no connection to another instance of the same application, even if it is running on the same workstation. In Visual WebGui, everything is run on the server, served by the same process for all instances of your application.

This means that a variable declared as static is shared with all instances of your application for all users. Simply put, opening your application on the same workstation in two different browser, they both access that same memory space occupied by that static variable. Opening another instance of your app on another workstation, it will also access that same static variable memory as the orther instances.

Remember that it makes no difference if the variables are declared private or not. As long as they are declared static, they are shared between all instances of your application.

To declare variables that would behave similar to what static variables do in Windows Forms, the closest you can get is using the Context Scope.

Cookie Scope

Cookie variables, or Cookies for short, in Visual WebGui are the same as Cookies in ASP.NET. Cookies provide a means in Web applications to store user-specific information. For example, when a user visits your site, you can use cookies to store user preferences or other information. When the user visits your Web site another time, the application can retrieve the information it stored earlier.

Cookies are stored by the browser locally on the client and all instances of your application on the same client running in the same browser will use the same Cookie.

Session Scope

Session variables in Visual WebGui are the same as Session variables in ASP.NET and enable you to store and retrieve values for a user as the user navigates the different forms that make up a Visual WebGui application.

As the name implies, Session variables are tied to a specific session. This means that two mainforms in your Visual WebGui application, running with the same session ID, will see the same Session variable.

There are some differences between browsers and operating systems, how they handle allocation of new session ID's. Some browsers will allocate new session ID for every new browser window opened while some will use the same session for all tabs and all windows (FireFox).

Two different workstations using the same application will get different session ID's allocated, and therefore they will be using different session variables.

Application Scope

Application variables in Visual WebGui are the same as Application variables in ASP.NET and are global to all instances of your application running from the same server. They behave very similar to Static variables in that sense.

Application scoped versus Thread scoped static variables

In general in ASP.NET, static variables are stored within the Application scope (AppDomain), which means that if a new thread is started, you still have access to the same static variables that you do in the original Visual WebGui UI thread.

This fact only applies to the "top level" variable references themselves. The implementation of how their properties behave, can as well be different. This is for instance the case for VWGContect and VWGContext.Current in Visual WebGui. The VWGContext is by itself a static refererence with an application scope and available to all threads. The Current property is however NOT, and referenced outside of the current Visual WebGui UI thread will always return null. This can of course easily be worked around by storing VWGContext.Current in another static variable and reference that variable from the spawned threads.

Context Scope

Context variables are a special Visual WebGui phenomenon. To understand the concept, it's most easy to think of a Visual WebGui application that consists of two mainforms, Form1 and Form2, which both are accessible externally (directly via browser as http://localhost/Form1.wgx and http://localhost/Form2.wgx). Each such mainform accessed like that directly from a browser will create it's own context (scope).

If you access those two forms from the same tab in the same browser, one after the other, both "applications" will have the same Session Scope, but they will have two different Context scopes.

In this sense, the Context scope behaves similar to static (global) variables in a Windows Forms application, which are global within each application.

Samples of useTips and TricksScope variables persistance over a switch of MainForm (Context.Transfer)

Switching to another form in your Visual WebGui application, by means of Context.Transfer, will preserve your Context Scope variables, and it will also preserve Session and Application scope variables. This effectively means that switching to a new form with this method will not create a new context, but preserve the same one.

Scope variables persistance over a redirect (Context.Redirect)

Redirecting to another Visual WebGui form within the same virtual folder, by means of Context.Redirect for instance, will destroy your current Context and create a new one in the form being redirected to. Your Context variables will there for be destroyed. Session and Application scope variables will remain intact.

When do you get a new context created

To have a new context created, any one of the following must take place:

  • You explicitly open a new form by changing the address bar in your browser and open a new form, new context will be created for that new form if one doesn't allready exist.
  • You issue a Context.Redirect to a new form, new context will be created for that new form if one doesn't allready exist.
  • Your session expires and you open/refresh your form again
  • You open your form in a new session / browser
  • You programmatically destroy the current context and open your form again


You do NOT get a new context created when you do a Context.Transfer to another form.

Dialog forms use the same context as the mainform

When opening dialog forms via show, showdialog etc., you are not creating a new context for that dialog form. The dialog form will use the context of the mainform. See example.

Cookies require one roundtrip to server to be stored

Using Cookies, you should be aware of that at least one roundtrip must be made to the server before the Cookie's value actually gets stored. Under normal circumstances this is nothing that should concern you, as you will not retrieve the Cookie until the next time you visit that website, anyway.

There are however cases where this might be of concern. Typical such case is storing user information in a cookie in your logon form, and then retrieving it within your mainform after successful logon. This case has been confirmed to have problems as within the mainform the Cookie you set in the logon form will be empty... at first.  Better way to transfer your logon information from the logonform to your mainform is to use the Session scope (the same place you set VWGContext.Current.Session.IsLoggedOn = True).

A Module in VB.NET is static and therefore global

In VB.NET a Module is static (global) by definition, so everything declared within a Module will be static in your application, and every variable declared in the Module will be referencing the same variable or memory space from all instances for all users of your application.

Limitations and workaroundsKeep Cookie data under 4 Kb

Allthough there is currently nothing in Visual WebGui that prevents you from storing unlimited amounts of data in Cookies, you should remember to keep total size of data stored in Cookies within 4Kb, otherwise ASP.NET will corrupt your Cookies.

SDK Version highlightsSee also
RererencesForum discussons




About the author

Related Articles

State Serialization  
Title Update Author
Tags: Architects, Developers, Visual WebGui Pipeline, 2. Intermediate, 3. Advanced, Optimizing Performance, Pre v6.3, v6.3, v6.4 and Later
10/Dec/2010    2010/12/10
Tags: Architects, Developers, Visual WebGui Pipeline, 2. Intermediate, 3. Advanced, Optimizing Performance, v6.4 and Later
24/May/2010    2010/05/24
Tags: Developers, Visual WebGui Pipeline, 1. Beginner, 2. Intermediate, Pre v6.3, v6.3, v6.4 and Later, 3. Advanced
23/July/2010    2010/07/23
Tags: Developers, Visual WebGui Pipeline, 1. Beginner, 2. Intermediate, Pre v6.3, v6.3, v6.4 and Later, 3. Advanced
24/Nov/2010    2010/11/24
Tags: Developers, Visual WebGui Pipeline, 1. Beginner, 2. Intermediate, Pre v6.3, v6.3, v6.4 and Later, 3. Advanced
22/Nov/2010    2010/11/22
Tags: Developers, Visual WebGui Pipeline, 1. Beginner, 2. Intermediate, Pre v6.3, v6.3, v6.4 and Later, 3. Advanced
23/July/2010    2010/07/23