making changes survive window resizes
June Lester
Hi. In my nav frame, I have buttons that change appearance on clicking.
But if the viewer resizes the window, Navigator/Communicator reloads the
*original* page, and the changes are lost. (MSIE merely refreshes that
page, apparently, so it doesn't lose the changes.)
Question: how can I keep changed pages through window resizes? For that
matter, how can I keep *any* changes in the state of a page (e.g.
parameter values set by the viewer) through a resize, if the original,
unchanged pages always gets reloaded? And howcum form entries *do* get
kept, but (according to my experiments) hidden form elements don't?
jason olmsted
I'm thinking you could update the values of everything on the page
onLoad with cookies (without expiration date so they die with the
session). Then, as you update the values, write it into the cookie.
When the page first loads, everythig would be blank, but subsequent
reloads wouldn't knock out the input.
However, I don't pay much thought to it, as how many people actually
resize the page while filling out the form, and what is the hassle if
they do. Design the form to be in bite-size chunks, in small wizard
like series and the motivation of the user to resize will be almost
non-existent.
jason olmsted
mailto:olm...@phat-media.com
http://www.phat-media.com/olm/
June Lester
In article <60okjj$och$2...@gte1.gte.net>, olm...@phat-media.com (jason
olmsted) wrote:
> On 29 Sep 1997 14:22:28 GMT, jale...@unb.ca (June Lester) wrote:
>
> >Hi. In my nav frame, I have buttons that change appearance on clicking.
> >But if the viewer resizes the window, Navigator/Communicator reloads the
> >*original* page, and the changes are lost. (MSIE merely refreshes that
> >page, apparently, so it doesn't lose the changes.)
. . . . . .
> However, I don't pay much thought to it, as how many people actually
> resize the page while filling out the form, and what is the hassle if
> they do. Design the form to be in bite-size chunks, in small wizard
> like series and the motivation of the user to resize will be almost
> non-existent.
Threre is no form, just buttons that control a content frame. And viewers
will very likely resize the window - in fact, they will probably be
advised to. And in any case, form entries *are* kept during resizes
andway - no problem. What I want to keep is the clicked appearance of the
buttons (as an indicator of where the viewer is in the material).
JCS
<XMP>
Store the state of your button into global vars into the master frameset:
top.button1 = true
I don't remember if N4 will re-execute the frameset document on a Resize,
and lazy to fire it to check. If it does, there are several other
workarounds. All you need is a safe and persistent storage place.
- For all NN browsers, this one with the well-known hidden frame:
Add a hidden frame to your top frameset, named, say, "hyde". Load it with
a regular form full of regular TEXT fields. Use them to store your values:
top.hyde.document.formName.elements[0] = "on"
or
top.hyde.document.formName.elements[0] = ""
so
if( top.hyde.document.formName.elements[0] )
// button 0 is "on"
else
// button 0 is "off"
At least and last, these values will survive a Resize -- or even a Reload,
thanks Netscape.
- For N4 only, a fancy undocumented goodie: you can add custom properties
to the Navigator object, they are persistent.
navigator.button1 = true
navigator.button2 = false
- You could use cookies, but it's annoying and many users just refuse
them, or tweak their cookie.txt file so as to prevent them w/o being
bothered.
- You could use donuts, but the previous ways are more convenients.
JCS
***
EMAIL : Changez ".X." en "." dans mon adel : ANTI
REPLY : Replace ".X." by "." into my email : SPAM
--
No browser were harmed during the making of this post.