Re: handling a recursive ASP.Net web page

Post #305,412 by jay 3/12/09 9:25:54 AM Reply	Re: handling a recursive ASP.Net web page Page_load will happen every time the page is loaded. So what you want to do is have ResearchButton_Click setup the values and then call SearchResults.aspx as if it was being called from StartSearch.aspx again. Jay
Post #305,417 by lincoln 3/12/09 10:16:07 AM Reply	That's what I wanted It took some time to get over the mental hump of having a page call itself. Back in the old VB6 world having a subroutine call the Form_Load event was no big deal; however, in the web world calling the Page_Load IS a big deal (you need to provide the two parameters that the system automatically fills in for you). I had to reset a bunch of variables, then reload them into Session variables, and then finally have the code do a "Response.Redirect("page") to call itself from scratch. Thanks everyone! "Chicago to my mind was the only place to be. ... I above all liked the city because it was filled with people all a-bustle, and the clatter of hooves and carriages, and with delivery wagons and drays and peddlers and the boom and clank of freight trains. And when those black clouds came sailing in from the west, pouring thunderstorms upon us so that you couldn't hear the cries or curses of humankind, I liked that best of all. Chicago could stand up to the worst God had to offer. I understood why it was built--a place for trade, of course, with railroads and ships and so on, but mostly to give all of us a magnitude of defiance that is not provided by one house on the plains. And the plains is where those storms come from." -- E.L. Doctorow
Post #305,436 by altmann 3/12/09 7:16:35 PM Reply	I don't get it (well, I do but,,,) ASP.Net is designed around the idea of pages posting back to themselves. You actually have to go out of your way to do otherwise. The difficulty in your situation is if you want to modify those search parameters in the QueryString for each new search. ASP.Net wants to treat a URL with a different QueryString like a new request for the page instead of a postback to the same one (in which case it would preserve and rebuild the state of the page and the event to call server-side in hidden VIEWSTATE form variables), so it doesn't let you just modify the QueryString and postback. You have to instead go through the trouble of rebuilding the QueryString yourself and calling Response.Redirect().
Post #305,440 by jay 3/12/09 11:08:04 PM Reply	Yep, it's a hack I'm sure there is a more ASP.NET style solution that involves reworking the connection object and moving the data pull into it's own subroutine that can be called from both the Page_load and button click event. Honestly though, even when I was coding ASP.NET, I went out of my way to minimize the use of it's event cycle. It's just adding a layer of obscurement to the web event cycle and exists only to try and make ASP.NET and windows forms have a similar event loop. Which doesn't archive anything, good form coding and good web coding still remain vastly different, because the bottlenecks are in different places and the platform fundamentally different. Jay
Post #305,442 by altmann 3/13/09 12:56:47 AM 3/13/09 1:08:02 AM Reply	Re: Yep, it's a hack I do think there's a misunderstanding by Lincoln of the magic ASP.net is doing behind the scenes here. It's understandable given his desktop VB background. I came at ASP.Net after doing plain old HTML form processing with Perl and CGI, so I knew there had to be something keeping state for me and rebuilding object trees server side and routing "events" via hidden form variables. But it's definitely geared towards "application" style design rather than "website" design. PS: The ASP.Net style design would have been to ditch the StartSearch.aspx page and just have a single Search.aspx page that only enables the results grid and does the DB work if there is content in the search textbox. Edited by altmann March 13, 2009, 01:08:02 AM EDT Expand All History

Welcome to IWETHEY!