Passing Values between forms in ASP.NET

[dpdoug]

ASP.NET seems to work so much different than ASP. I'm having difficulty passing values between forms.

I've tried this in the called form:

strStore = Request.Form("cboStore")
strCompany = Request.Form("cboCompany")

And I've tried this in the calling form -- trying to save them to a session variable and then picking it up in the called form:

Private Sub cmdNavegate_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdNavegate.Click
      Session("cboStore") = Me.cboStore.SelectedItem.Value
      Session("cboCompany") = Me.cboCompany.SelectedItem.Value

      Response.Redirect("[URL unfurl="true"]http://localhost/rsc/profile_add.asp")[/URL]
End Sub

then in the called form:

strStore = session("cboStore")
strCompany = session("cboCompany")

But neither works. Can anybody give me a hand with this, please? Thanks, everybody for your patience.

dpdoug

 

[Custom24]

I've never used form variables because they do seem to work differently in asp.net

However, session variables should work. What error or behaviour are you getting?

One last option for you is to use the query string - embed the stuff in the url as follows

in the posting form

response.redirect ("profile_add.asp?Store=" & server.urlencode(Me.cboStore.SelectedItem.Value) & "&Company=" & server.urlencode(Me.cboCompany.SelectedItem.Value), true) 'true ends processing for this response, since you've redirected

And in the receiving page

strStore = request.querystring("Store&quot
strCompany = request.querystring("Company&quot

Mark

 

[Isadore]

I have heard several on this thread argue that if given the choice, querystring passage of variables is the preferred method as it requires less server resources.

 

[Custom24]

Yes I agree. The other advantage is that you don't have a session time out limit, and you can do VaryByParam page caching.

One disadvantage is that with a session variable, you can stick any object in there. But since that really only works 100% if you are using the InProc session state mode, and since that mode is not 100% compatible with a web farm or even a web garden, it's not so much of a disadvantage after all.

Mark

 

[bigfoot]

Create a module and use Public variables.

 

[BoulderBum]

dpdoug,

Your session syntax is correct. "session" should be "Session", but if that doesn't change things, the problem is most like in your page settings or something.

others,

Another downer is that the QueryString has a length limit, and isn't secure. You have to watch out for something like: page.aspx?user=admin, which can be easily added to a URL with no tool but a browser. You don't want to store sensitive, user-specific information in the QueryString.

 

[RichS]

I second BigFoot

>>>Create a module and use Public variables.<<<

 

[BoulderBum]

&quot;Create a module and use Public variables.&quot;

One way ASP.NET differs from .NET application programming is that data is lost/ dumped after page processing to conserve server resources. Creating a public Property or variable for an instantiated class won't save information unless it is explicitly stored in some way, which brings us back to Sessions, QueryStrings, Cookies, ViewStates, HiddenFields, and the like.

 

[RichS]

I am using a global variable in a separate module to pass a Primary Key ID from one page to another when I do a Response.Redirect(&quot;someOtherPage.aspx&quot. I am also storing some application and user preferences from the database and using them throughout the application (one is g_IsValidUser which is checked in every page.

Data is only dumped from a pages ViewState after processing but globals declared in outside modules are retained in memory.

 

[lehuong]

The deer has good eyes.... = good idea
Le

 

[Custom24]

This is interesting. I would have said the same as Boulder Bum - ASP.net forgets everything between posts unless told explicitly to remember it.

Yet it does work. However, it is still not suitable for the question which was asked. As far as I can tell, these public variables have application, and not session scope.

What, therefore, if two clients are connected? The first sets a public variable and the server sends back a response.redirect to some other page. But before the first client posts back the request for the other page, the second client alters the value of the public variable in the first page. Then, both clients end up at some other page.aspx, both seeing the same information, but the first is looking at the wrong information.

Still, though, this technique might be useful where application scope is required, but even then I'd tend to use the application object, because you get options to persist that to disk via SQL server or a separate state server.


Mark

 

[RichS]

Custom24,
You are correct: I can't use this for user settings, thanks for the heads-up.

Rich