Hey Steve, You don't need to do an ELSEIF. Anything ELSE other than 1 would go to the business as usual page.
If you do an ELSEIF @@user$hit=0 it wouldn't work because the variable doesn't have a value of 0, it's just non-existant. 0 is an actual value, whereas NULL has no value. Rick Sanders ----- Original Message ----- From: "Steve Campbell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 5:15 PM Subject: Re: WiTango-Talk: overcoming the browser back button > Hey RIck.....one thing here > > On the initial form page after I put the code.. > > <@ASSIGN Name="hit" VALUE="1" SCOPE="USER"> > > Then for the if action afterwards where the insert goes... > Its' <@IF> = 1 > > Then for th eelseif it's > > <@ELSEIF> = 0 > > Is this correct? > > Thanks > > Steve > > > > > > Hey Steve, > > > > What I do is just <@ASSIGN NAME="hit" value="1" scope=user> > > > > Then, in the taf I do a condition: > > > > IF Action > If @@user$var=1 Sorry, you've hit the page already ELSE ACTION > > > Business as usual. > > > > Rick Sanders > > > > ----- Original Message ----- > > From: "Steve Campbell" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, February 24, 2003 1:38 PM > > Subject: Re: WiTango-Talk: overcoming the browser back button > > > > > >> So.. > >> If am following.. > >> > >> <@ASSIGN NAME="myname" SCOPE=USER VALUE="<@VAR lastpagehit>"> > >> > >> Is this what you are suggestioning? > >> > >> Steve > >> > >> On 2/24/03 12:35 PM, "Rick Sanders" <[EMAIL PROTECTED]> wrote: > >> > >>> I was just about to suggest that. > >>> > >>> Assign a variable at the next page. If the person goes back and > > re-submits, > >>> the variable was already assigned, so you can throw whatever error or > >>> message you want. > >>> > >>> Rick Sanders > >>> > >>> ----- Original Message ----- > >>> From: "Atrix Wolfe" <[EMAIL PROTECTED]> > >>> To: <[EMAIL PROTECTED]> > >>> Sent: Monday, February 24, 2003 1:32 PM > >>> Subject: Re: WiTango-Talk: overcoming the browser back button > >>> > >>> > >>>> well i think one way to implement this would be to have a user$ > > variable > >>>> which kept track of which screen they were looking at. That way, if > > they > >>>> requested a screen which didnt match the screen they should be seeing, > > it > >>>> could show them a "warning this page has expired" screen or maybe just > >>>> redirect them to where they should be. Im not sure if theres an easier > >>> way, > >>>> but this way seems pretty simple. > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: "Steve Campbell" <[EMAIL PROTECTED]> > >>>> To: <[EMAIL PROTECTED]> > >>>> Sent: Monday, February 24, 2003 10:22 AM > >>>> Subject: Re: WiTango-Talk: overcoming the browser back button > >>>> > >>>> > >>>>> Great idea Rick...wonder if anyone has ported that over to a taf yet? > >>>>> > >>>>> Steve > >>>>> > >>>>> > >>>>> On 2/24/03 12:08 PM, "Rick Sanders" <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>>> What about making the page expire like they do on the PayPal website? > >>>> When > >>>>>> you click back, you get the page expired message. > >>>>>> > >>>>>> Rick Sanders > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>> From: "James MacFarlane" <[EMAIL PROTECTED]> > >>>>>> To: <[EMAIL PROTECTED]> > >>>>>> Sent: Monday, February 24, 2003 12:51 PM > >>>>>> Subject: RE: WiTango-Talk: overcoming the browser back button > >>>>>> > >>>>>> > >>>>>>> In short, there is *NO WAY* to disable the BACK button. > >>>>>>> > >>>>>>> One thing you can do is have the form submit itself to a page that > >>>>>> generates > >>>>>>> a redirect to the following page. This way if the user presses BACK > >>>> they > >>>>>>> will go back to the redirect page, which will send them back forward > >>>>>> again. > >>>>>>> > >>>>>>> This will not stop the user from using HISTORY to go back though. > >>>>>>> > >>>>>>> Another technique is to use a hidden frameset to store some 'page > >>>> state' > >>>>>>> variable. Whenever a page loads, you can have it run a javascript > >>>> function > >>>>>>> in the hidden frame. When page TWO loads you can have a variable on > >>> the > >>>>>>> hidden page set to "2", so if someone goes back to page ONE, the > >>> script > >>>> in > >>>>>>> the hidden frame can detect that they've already been to page TWO > > and > >>>> send > >>>>>>> them back there. > >>>>>>> > >>>>>>> There are many things you can do, none of them are 100% fool-proof. > >>>> These > >>>>>>> ones should work pretty well though. > >>>>>>> > >>>>>>> - James > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Steve Campbell [mailto:[EMAIL PROTECTED] > >>>>>>> Sent: Monday, February 24, 2003 12:19 PM > >>>>>>> To: [EMAIL PROTECTED] > >>>>>>> Subject: Re: WiTango-Talk: overcoming the browser back button > >>>>>>> > >>>>>>> The mail action is fixed...the logs showed that I relayed myself > >>>> out..so > >>>>>> the > >>>>>>> idea to que is a good one..and iss now working. > >>>>>>> > >>>>>>> Now on to the next problem. > >>>>>>> > >>>>>>> I have a simple form entry, that checks against a few columns to > >>> make > >>>>>> sure > >>>>>>> the user has entered data in the form already. I am only allowing > > the > >>>> user > >>>>>>> to enter once. > >>>>>>> > >>>>>>> I have found that hitting the "browswer back" button that they can > >>> keep > >>>>>>> entereing. > >>>>>>> > >>>>>>> Anyway around this? > >>>>>>> > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> Thanks for eveyrthing guys.. > >>>>>>> > >>>>>>> > >>>>>>> > >>>> > > ________________________________________________________________________ > >>>>>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > >>>> [EMAIL PROTECTED] > >>>>>>> with unsubscribe witango-talk in the message body > >>>>>>> > >>>>>>> > >>>> > > ________________________________________________________________________ > >>>>>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > >>>> [EMAIL PROTECTED] > >>>>>>> with unsubscribe witango-talk in the message body > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>> ________________________________________________________________________ > >>>>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > >>> [EMAIL PROTECTED] > >>>>>> with unsubscribe witango-talk in the message body > >>>>> > >>>>> > >>>>> > > ________________________________________________________________________ > >>>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > > [EMAIL PROTECTED] > >>>>> with unsubscribe witango-talk in the message body > >>>> > >>>> > > ________________________________________________________________________ > >>>> TO UNSUBSCRIBE: send a plain text/US ASCII email to > > [EMAIL PROTECTED] > >>>> with unsubscribe witango-talk in the message body > >>>> > >>> > >>> > >>> ________________________________________________________________________ > >>> TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > >>> with unsubscribe witango-talk in the message body > >> > >> > >> ________________________________________________________________________ > >> TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > >> with unsubscribe witango-talk in the message body > >> > > > > > > ________________________________________________________________________ > > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > > > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
