Probably the easiest way is to not get to that point at all in the first place. Just use a client-side javascript form validation script to prevent un-filled fields from even occurring.
Another way around ths is to create tempory session variables on the processing page, and if some of the form fileds( ie : all the form fields are not filled out) you could redraw the form and fill the fields in with those temp vars. Hope these help you out, Joe :) Compman86 <[EMAIL PROTECTED]> wrote in message 007f01c1b016$bbb45010$dd563944@cc1966780a">news:007f01c1b016$bbb45010$dd563944@cc1966780a... > I posted about this a few days ago. I received several responses but > none of them were very helpful (thanks for the effort though). I finally > figured out what it was by process of elimination. At the top of my > registration form, I put session_start() just like I did for all my > other scripts. Well it turns out that by doing this, for some reason, it > clears the form. I have a hunch that the cookie request by > session_start() has something to do with it. Well, the only reason > someone would be at the registration form would be if he/she was not a > member, therefore the session ID would be pointless. > > This is the major flaw of PHP's built in sessions imho: If a user > disables cookies, the session functions assign the session ID to the > constant SID. However, if the SID is not passed on religiously, a new > session will be made. In an instance like this where session_start() > cannot be used, you can't pass on the SID. It seems like I'm just going > to resort to requiring that my users enable session cookies. The hastle > of making the code to use both SID and/or cookies just doesn't seem > worth it. If anyone has any ideas of a resolution to this problem, feel > free to post here or email me. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
