I was hoping to get some input on how you would attack this problem.<BR><BR>I'm building the signup process for a site. It's a 3 or 4 page process, thoughout which I need to hold the data and only save it if they finish the entire thing. I was going to build a component to encapsulate all the business logic, and just write values in to it from each of the pages as they step through the process. What I'm not sure about is the best way to pass this component along. Hand it from page to page? Or should I roll all of it into one page and just display one page of it at a time? Or should I make all of the pages post back to a single page that handles the processing?Download the Microsoft.Web.UI.WebContols and use a TabStrip Control in conjuction with a MultiPage Control. One form, one post, piece of cake. Of course there are many other ways to do it, but this one seems the easiest.It's a good suggestion, and I think I'm going to do it this way. However, after getting just a little ways into it I came to one of my big frustrations.<BR><BR>My designer provided me with the signup pages, signup1, signup2, signup3. Now in order to make these work with the multipage, I have to go into each file, copy the HTML that changes from page to page (ie everything inside the <form> tag) and paste it into each pageview item. Ok, no big deal. However, it doesn't automatically create the "textbox" instances for me in the codebehind page, so now I need to manually create those. Or I have to create them in the original file and cut/paste them into this new page. Ok, fine. So I click back into design view to rename one of the text fields...oh wait, you can no long do anything in design mode because it considers the entire "multipage" object as a single item, and does not allow you to edit the HTML from the visual designer.<BR><BR>Is it just me, or did I just completely lose all ease-of-use? Ok so the multipage will work really nicely, and I'll save time in having to pass stuff back and forth, but it'll take me 10x as long to make any changes or whatever because I have to cut and paste everything in HTML instead of just clicking it and editing a property.<BR><BR>BTW, I'm not ranting at you ChrisN.Based on what you want to do, you'll have to do some work. Granted, VS.NET has some nice features that quicken the process, but for the most part, as a professional developer, I WRITE code - all day, everyday. At least you can cut and paste. For the most part, we have to write everything by hand and we prefer it that way: better understanding, more control. Just start typing and I promise that you will have learned something new and you will be pleased with the outcome.This isn't about WRITING code or learning anything...this is about accomplishing work in order to produce a produce that we can make money on. So many things out there seem to be centered around this idea that the person trying to code a page is the same person that is laying the page out...which explains why so many sites out there look like trash.<BR><BR>I have professional designers and production people that do nothing but design stuff and then turn that "stuff" into HTML pages. If a design changes one way or another, the structure of the HTML could completely change. Then I have 2 choices. I can waste my time and talent cutting and pasting HTML into something like a multipage control, or I can be smart and build the whole thing so that my production staff can edit it themselves. This is accomplished very nicely with code behind, but is completely invalidated by using a multipage control.<BR><BR>So, the bottom line is that I'm gonna end up doing this in multiple pages simply because it's faster, and allows me to allocate my own time to more valuable items (like business logic).<BR><BR>By the way, as a professional developer, I also write code all day every day. But apparently unlike you, I choose to avoid wasting time writing things that can easily be autogenerated. Doing everything by hand is great for learning stuff, but once you understand what is going on, speed is king.So do what ya gotta do, man.... I wasn't ranting on you, just saying that I don't see the big deal about writing a couple of PageView(s). If it doesn't fit with your development team's way of doing things, then change the routine or use another approach. The point that I was trying to make was that, given the task at hand, there really is nothing that you are going to be able to drop onto a web form and just set some properties/parameters - you're gonna have to write something. <BR><BR>In reference to:<BR><BR>"But apparently unlike you, I choose to avoid wasting time writing things that can easily be autogenerated."<BR><BR>Here is your Gold Star <<<*>>>, Mr. Speedy 
Obviously this was going to require manual coding no matter how it was done. What I was trying to say, was that I didn't want to lose the ability to update things (like field names, sizes, column widths, font color, etc, etc) that you normally can through a visual tool. Paging through an 800 line HTML page to find the name of a text box doesn't help you understand anything any better than just selecting it and changing the name in the property. So...I don't want my coding solution to interfere with HTML editing capabilities. Maybe that's a little more clear.
Obviously this was going to require manual coding no matter how it was done. What I was trying to say, was that I didn't want to lose the ability to update things (like field names, sizes, column widths, font color, etc, etc) that you normally can through a visual tool. Paging through an 800 line HTML page to find the name of a text box doesn't help you understand anything any better than just selecting it and changing the name in the property. So...I don't want my coding solution to interfere with HTML editing capabilities. Maybe that's a little more clear.