Cross-page posting of data.

I have been trying to cross-page post data that is created in a source page codefile to a target page that graphically displays that data. After much searching, it appears that the only type of data that can be cross-page posted is data that is associated with a source page control. IS THIS ACTUALLY THE CASE? OR IS THERE SOME WAY TO CROSS-PAGE POST DATA THAT IS NOT CONTAINED IN A SOURCE PAGE CONTROL.

I would also like to know if a table containing data qualifies as a control. I have experimented with setting data in a source page table, then attempting to cross-page post, but it is unclear to me how to use the table cell IDs and pair them with the cell 'values'. Since the data that I am interested in cross-page posting is float data, can such float data be posted as such, or must all data posted be of the String type?

I have used the following references for help on this matter:
For info on how to post from one ASP.NET page to another, see:
http://msdn.microsoft.com/en-us/library/ms178139.aspx
http://msdn.microsoft.com/en-us/library/ms178140.aspx

How to: Pass Values Between ASP.NET Web Pages
http://msdn.microsoft.com/en-us/library/6c3yckfw.aspx

But, as is so often the case, none of these provide a very detailed example and none deal with passing data that is not contained in a source page control.

Your help greatly appreciated.

HTTP is a stateless protocol meaning what you do in one connection has no influence/knowledge about what you do in another connection (request to the web page).
Basically this means what ever the user does on one web page is not known by the next web page he requests. Stateless.
Therefore if you need to move data around between pages you have a number of options.

If the user is clicking on links, query strings are an easy way (and good way) to go. That's the last of your links. Simply append the querystring variables to your link and you can read them on your target page as per the link. This sounds like the way you should go.

Another way to "shared" information between the pages are via the Session object which is - as the name says - tied to the specific session. This is an easy way to share information, but sessions can time out etc.

A third way is to use cookies. Not recommended for simply sharing data across the pages but more as a "static" information which helps recognize the user or preference information (which language the user have selected)

A fourth way is the Application object. But don't go there. :D

Thank you for taking the time to examine this problem.

There must be some simple mistake that I have been making. Because of the many subtleties of the problem, I have posted a small demo ASP.NET Website (built using Visual Studio 2008) to demonstrate the problem.

I'll take a look at it later today when I get home from work and see if I can find out what goes wrong :)

The problem with your example is that you're repopulating the text boxes on your Page_Load.

When you're reloading the page, you instantiate the variables (f1 to f9) again and assining their value to the textboxes, thus writing 0.0 into every textbox (instantiated value of a float).

So to get it to work, remove all the lines in your page_load as they're not needed in your example. If you want them in your page_load regardless, remember to wrap code you do not want run when posting back within:

Code:

---

if (!Page.IsPostBack)
        {

        }

---

which means it'll not be run when an event triggers a resubmit (for example a button click).

Then comment in your assignments of the strings s1 to s9 from the textbox values (ignore the f1 to f9 here) in your buttonSend_Click method, and it should work.
This should leave you with something like this:

Code:

---

public partial class _Default : System.Web.UI.Page
{
    // define 9 strings as class members
    protected float f1, f2, f3, f4, f5, f6, f7, f8, f9;
    protected String s1, s2, s3, s4, s5, s6, s7, s8, s9;

    // When the page first loads, the 9 float variables
    // are set to 0.0 and their representative strings are
    // set in the 9 text boxes
    protected void Page_Load(object sender, EventArgs e)
    {
    }

    protected void buttonSend_Click(object sender, EventArgs e)
    {
   
        // get the string values from the controls
        s1 = txtV1.Text;
        s2 = txtV2.Text;
        s3 = txtV3.Text;
        s4 = txtV4.Text;
        s5 = txtV5.Text;
        s6 = txtV6.Text;
        s7 = txtV7.Text;
        s8 = txtV8.Text;
        s9 = txtV9.Text;  // Text gets or sets the text content of the System.Web.UI.WebControls.TextBox control
 
        Response.Redirect("TestTarget.aspx?Field1=" + s1 + "&Field2=" + s2 + "&Field3=" + s3
            + "&Field4=" + s4 + "&Field5=" + s5 + "&Field6=" + s6 + "&Field7=" + s7
            + "&Field8=" + s8 + "&Field9=" + s9 );
    }

  // Clicking this button generates 9 random floats and
    // sets their string representation into 9 textboxes
    protected void btnRandom_Click(object sender, EventArgs e)
    {
        //====== randomize 9 values between 0.0 and 1.0
        Random random = new Random();
        f1 = (float)random.NextDouble(); f1 *= 100.0F;
        f2 = (float)random.NextDouble(); f2 *= 100.0F;
        f3 = (float)random.NextDouble(); f3 *= 100.0F;
        f4 = (float)random.NextDouble(); f4 *= 100.0F;
        f5 = (float)random.NextDouble(); f5 *= 100.0F;
        f6 = (float)random.NextDouble(); f6 *= 100.0F;
        f7 = (float)random.NextDouble(); f7 *= 100.0F;
        f8 = (float)random.NextDouble(); f8 *= 100.0F;
        f9 = (float)random.NextDouble(); f9 *= 100.0F;

        //====== set random doubles into the table
        txtV1.Text = Convert.ToString(f1);
        txtV2.Text = Convert.ToString(f2);
        txtV3.Text = Convert.ToString(f3);
        txtV4.Text = Convert.ToString(f4);
        txtV5.Text = Convert.ToString(f5);
        txtV6.Text = Convert.ToString(f6);
        txtV7.Text = Convert.ToString(f7);
        txtV8.Text = Convert.ToString(f8);
        txtV9.Text = Convert.ToString(f9);

    }

 }

---

To explain a bit more.
When you load a webpage it is executed like this: page_load --> event handling (many other events are run around it as well, but these two are your two main when learning the concept).
That means if you write things to your textbox'es in Page_Load - you'll overwrite the data present from the submitting (the so-called "viewstate" - the data is still accessible, but not via the .Text property on textboxes).
Take a look - amongst others - here: http://msdn.microsoft.com/en-us/library/ms178472.aspx for more information but it can be a bit daunting for a newcomer to the language/mechanics.

For now - just remember, things you do in your Page_Load is executed before eventhandlers like your button-click handlers. (So remember the if(!Page.IsPostBack) - you'll use that a lot)
Therefore re-declaring parameters and assigning them to a textbox will happen before you try to read from them, and therefore you read the newly declared/instantiated values and therefore it would look like it didn't work despite it working as intended. :)

I hope this helps. :)

Alsvha, thankyou for your response. You are entirely correct. When I removed what I thought was one-time initialization of page variables from the Page_Load method of the source (default.aspx) file, the variables in the textboxes, converted to strings and sent via the command:

Code:

---

Response.Redirect("TestTarget.aspx?Field1=" + s1 + "&Field2=" + s2 ...etc)

---

sends the desired value string representations to the target page.

However, I notice that if I try to send the variables (floats v1,...,v9) by converting them directly into strings rather than using the string reps from the source page text boxes,

Code:

---

        s1 = Convert.ToString(f1);
        s2 = Convert.ToString(f2);
        s3 = Convert.ToString(f3);
//...

---

and using the same Response.Ridirect command as above, NOTHING is received by the target page. I interpret this result as indicating that if one is to use Response.Redirect in the manner described here, that one must use string values derived from existing page controls.

This latter observation concerns me greatly, because I had planned to use code behind the source page to make some rather elaborate database dependent calculations and seamlessly send them to a graphical display page. Representing all of the calculated results on the original source page prior to sending them to the graphical display page would not be very seamless and would probably slow the whole process considerably.

This gets me back to one of my earlier posted questions. Namely, how does one send raw data (i.e., floats) to another web page (without posting them first as strings in a control)?

I would like to thank you again for your most helpful comments. Clearly, I have alot to learn about ASP.NET. :)

I'll try to tackle your remarks to the best I can:

Quote:

---

Originally Posted by Mike Pliam

<snip>When I removed what I thought was one-time initialization of page variables from the Page_Load method of the source (default.aspx) file<snip>

---

You must remember the stateless methodology of the HTTP protocol here.
Each call to the page is an independent call. Therefore what you thought is a "one-time" initialization, is a one-time *per* call to the page.
So each time you hit (or anybody does) the page, it'll run.
That's often a large point of confusion from traditional application and service development and one major reason why - for example - database calls and other expensive resources needs to be used properly.
So each time you call a page, you'll reinitalize the page, as the page runs. This means calling the page, event handling and so on. Therefore the "!Page.IsPostBack" is very important, because then you can initialize things needed for the page the first time the current session triggers the page.

ASP.NET operates with a concept called "viewstate" which you can see if you view-source on a rendered asp.net page. It is basically a hidden field containing the page data making sure you have access to them after a post-back. (for example clicking a button).

Secondly - "primitive" data types in .NET are initialized with their default value, so you do not really need to initialize float data types before using them.

Quote:

---

Originally Posted by Mike Pliam

<snip>
However, I notice that if I try to send the variables (floats v1,...,v9) by converting them directly into strings rather than using the string reps from the source page text boxes,

Code:

---

        s1 = Convert.ToString(f1);
        s2 = Convert.ToString(f2);
        s3 = Convert.ToString(f3);
//...

---

and using the same Response.Ridirect command as above, NOTHING is received by the target page. I interpret this result as indicating that if one is to use Response.Redirect in the manner described here, that one must use string values derived from existing page controls.
<snip>

---

QueryStrings aren't tied at all to controls, they existed long before ASP.NET.
QueryString is basically a key/value collection however, it is a string key/value collection (only way to transmit data via QueryString is via strings, hence the name), and in the object behind the scene it is comma-separated.
And therefore you can post - for example - floats into your QueryString (also without having to parse them into a string variable first), but it will be converted to a string in the QueryString.
It might be the conversion which goes wrong in your second attempt. Try posting the code and we can take a look at it.

If you need to move larger objects or a lot of data between the pages, you'll need another methodology then querystrings, either using the Session object, or by storing in - for example - a database so you can read it on another page.

Quote:

---

Originally Posted by Mike Pliam

<snip>
This latter observation concerns me greatly, because I had planned to use code behind the source page to make some rather elaborate database dependent calculations and seamlessly send them to a graphical display page. Representing all of the calculated results on the original source page prior to sending them to the graphical display page would not be very seamless and would probably slow the whole process considerably.
<snip>

---

Now, I know this is just a test example of sorts (I hope), but in your example, you do not really need to send your data to another page.
You can let your default.aspx handle the data in a button click. You can create a class liberary you can reference from your website and let that handle it possible calculations, so you can let default.aspx generate data - parse it to a class liberary which does calculations - and show the data again on your default.aspx.

Quote:

---

Originally Posted by Mike Pliam

<snip>
This gets me back to one of my earlier posted questions. Namely, how does one send raw data (i.e., floats) to another web page (without posting them first as strings in a control)?
<snip>

---

floats can be send via QueryString, but will be converted to strings, meaning you'll need to convert them back again as floats on your target.
If you do not want to convert, you can - as mentioned - either use Session or store it some place and fetch it on another page (database round trip).
Floats however, are mainly kept in QueryString or Sessions.

Quote:

---

Originally Posted by Mike Pliam

<snip>
I would like to thank you again for your most helpful comments. Clearly, I have alot to learn about ASP.NET. :)

---

Many of the issues you're running into isn't as much ASP.NET - but more simply "web development", (stateless, querystrings, session objects etc) but there are a lot of things and techniques to get the hang on, but it looks to come along fast if playing around with it.

Two of the best pieces of information (IMO) about ASP.NET pages to understand is the difference between PostBack and "not PostBack" and that there are a number of "page events" and the general order those are executed in.
These two pieces of information will help you tremendously as you dig deeper into ASP.NET :)

Alsvha, let me thank you again for taking the time to answer these questions. Your response provides a very useful tutorial on cross-page posting of data. There is quite a bit to digest here. I will explore each of the points that you have made. :)

No problem - it's why we troll these forums :)