Yes, that's exactly the way you should do. Stay on the page in case of an error and if all things are fine, redirect.

What I meant with a one page wizard is something you can build your self. I was referring to a single ASPX page with multiple "regions" (often created with the <asp:Panel> control.
Then, instead of transferring to the next page, you simply hide the current panel, and display the next panel as in the following pseudo code:

If Panel1IsValid Then
  Panel1.Visible = False
  Panel2.Visible = True
End If

This needs some work, because you need to determine what "page"/panel you're on, and act accordingly. However, once you understand how to build such a thing it can be quite a good solution. You only need one page, so maintenance is easier. Also, because all controls are located on one page, you can let the ASPX page handle ViewState for the page and finally, it's easier to move questions around on the panels, rather than between pages.

I think you're confusing Shared Members with session variables or so. Shared Members belong to the entire application / assembly of the application. They are often used to create functions that don't need a member instance to operate. This can useful for general helper functions.
You can also keep track, for example, of the number of instances of a specific class you created. Shared Members should *not* be used to store user-specific data like error flags.

Do a Google search for "Shared Members .NET" and you'll find a lot of info.

Cheers,

Imar

Thanks again Imar

As Imar has described, Shared members are basically globally accessible members that are shared while the class type (keyword being 'type' not 'instance') is visible to the execution scope of the application. Where this comes into play with ASP.NET is that there is basically 1 execution scope. When the application is loaded it's running under the master process of the ASPNET_WP process under IIS. So every page requested could potentially see the same shared member and therefore your page specify errors in your example would cross user boundaries.

I think with a little re-working of your pages and handling things as the ASP.NET postback model promotes, you'll find that you don't need the extra stuff you've put in your original code.

Thanks Planoie,

So what technique would you recommend overall for sharing variables between pages. My experience is in classic ASP, so I have used the QuerySring and hidden form variables extensively. The problem with those of course, is that they get messy when you have a lot of them (especially when passing variables that aren't necessarily needed by the page you're passing to, but might be by the one after that).

Thanks!

The session collection is the recommended place. It's a discretionary thing. You could also use the querystring too depending on what type of information you are dealing with. For example, when my users log in, their user information (used throughout the application) gets populated to the session collection. But when we have a product list on one page, then you click a link to view one product, the product to view is put on the querystring. I usually ask myself "how long do I need this data/value to be persisted/available. Fortunately with .NET, when you use the postback model, if you are sitting on a page with a url like this: "viewproduct.aspx?product=12345" you don't have worry about ever re-writing that url because the .NET web form will always post back to the same URL. So in that page you can use the value from the query string as an automatically persisted variable during the webforms's life cycle. It's kind of like a shared/static var or a viewstate value. This is how I approach my page design.

IMO session variables can be used "easily" as long as your application is not going to on a web farm. If at all it is in a web farm we need to do some extra code in configs. So in those cases I prefer persisting the values in a base handler.

Best Regards
Vadivel

MVP ASP/ASP.NET
http://vadivel.thinkingms.com

Vadivel-

You can use SQL based session management to eliminate the problem of a multi-server environment.

How do you persist the values in your base handler?