Hi Snib:

I understand.

Thanks for your responses. You've been a big help.

Bottom line is that content-changing DHTML involves a lot more work than I thought it did. Not only does one need to make the changes, but one also has to keep track of them as they are made so you can return to the last state if a refresh or back button are used.

Like most really cool things, best used sparingly.

Again, thanks. Much appreciated.

JK

No problem.

http://msdn.microsoft.com/library/de...ence_entry.asp
http://dynamicdrive.com
http://javascript.internet.com

Snib

P2P Member
<><

I still think that page Expiring is better that disabling any button of browser. Why we should close the way for user while u can use of programming.

Always:),
Hovik Melkomian.

Hello Hovik:

I am in total agreement with you about the Back button, as I believe Snib is. Any other route is a better choice.

In fact, the route I took involves neither cookies nor page expires.

I found that since the controls maintained the correct state (values) after a Refresh or Back button, I could reapply any DHTML generated content changes by writing a routine for the 'onload' event. The routine simply looked at the controls that cause DHTML generated content change, determined their current value, and applied the changes as appropriate.

One more point: I mentioned that the controls maintained their state (values) after a Refresh or Back button. That is true for Mozilla 0.7 and Netscape 7.1. Refresh, in Explorer 6.0, acted just like Reset, the form was cleared of all values. Not just in the form I created, but in other forms I checked it against.

JK