About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 35 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

Blog Search


(Supports AND)

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

Being in the dictionary is not a badge of honor. People aren't limited to words I've managed to capture and pin down. A dog doesn't have to be registered with the American Kennel Association to be a dog. It still fetches your slippers; it just isn't pedigreed.

Erin McKean, American lexicographer



Navigation





<April 2025>
SMTWTFS
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Categories

  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  

Contact Me

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 4/17/2025

Totals
Posts - 2657
Comments - 2678
Hits - 2,737,884

Averages
Entries/day - 0.33
Comments/entry - 1.01
Hits/day - 344

Updated every 30 minutes. Last: 8:10 AM Pacific


  12:28 AM

Update Part 2 of this information has been posted here.

Another little Whidbey thing. In old-style ASP, programmers created multi-page forms by setting the action attribute of the <form> tag to point to the next page in line. In ASP.NET, this isn't possible; the page owns that action attribute, and whatever you might put there, the page will post back to itself.[1] The canonical solution in ASP.NET is to use Server.Transfer, which retains your post info (in Page.Context) but transfers control to another page. Two problems: 1) Lots of people didn't/don't know about this, and 2) because the client URL doesn't change, there can be some of those famous "unpredictable results" if the user hits the Back button.

In Whidbey, they're introducing a formal cross-page posting technology. It's pretty neat. You specify a target URL not on the <form> tag, as you might think, but as a property of the button. When you click that button, the current page is posted to the page in the button's PostTargetUrl property. It works just like you'd expect -- the target page is displayed in the browser, and its URL is properly displayed. If you hit the Back button, you return to the source page.

To provide proper functionality, there are a few other changes. One is that the target page ignores viewstate from the source page. (I haven't sorted this out completely, but it looks like this might be done by a handler that strips the info.) Pages also now have a PreviousPage property that gets a reference to the calling page, much like how you can do after Server.Transfer does. In theory, you can strongly type the PreviousPage property, but I haven't gotten that to work. Even so, you can use FindControl to get the values of controls on the source page.

Here's a simple example. This is the source page:


<%@ Page Language="VB" %>
<html>
<body>
<form id="form1" runat="server">
<asp:TextBox runat="server" ID="textbox1" text="" />
<br />
<asp:Button Text="Target Page" Runat="Server" PostBackUrl="target.aspx" />
</form>
</body>
</html>
Here's the target:

<%@ Page Language="VB" %>
<script runat="server">
Sub Page_Load()
Dim tb As TextBox
tb = CType(Page.PreviousPage.FindControl("textbox1"), TextBox)
label1.Text = tb.Text
End Sub
</script>
<html>
<body>
<form id="form1" runat="server">
<asp:Label Runat=Server ID="label1" text="" />
</form>
</body>
</html>
If you're feeling nostalgic, you can use olde-tyme Request.Form to get the values of controls posted with the page.

When I get strong typing sorted out, I'll illustrate that, too.


[1] A hacky way around that is to set the action attribute in client script. However, this often results in viewstate corruption errors, so you have to know what you're doing.

[categories]   ,

[2] |