back/forward confined to one stack

[Richard Gaskin]

Excellent work, Charles. I've quoted your full post here because your 
script makes good learning material for others who may have the same 
need, well worth a second read.

As much as I appreciate the convenience of "go back", like you I've 
found that I often need more control of what's included in the backList 
and what isn't.  As you've found, maintaining your own history only 
takes a couple dozen lines in all, and gives you complete control over it.

Good job!

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com



Charles Hartman wrote:
> I'm positively childishly pleased to report that my simple  
> implementation of a history-list for a single stack or substack  works. 
> It confines itself to that stack alone (unlike the Rev- internal 
> commands relevant to "recent" -- but thanks to Jacque for  her 
> suggestions that made me learn more about those). Assuming that  each 
> card in the relevant stack has a Back button whose mouseUp  handler just 
> sends the command 'backButton' and a Forward button that  sends 
> 'forwardButton', the handler's in the stack's script that I've  copied 
> below seem to do the trick.
> 
> I don't know if anybody else needs this -- or if, as I'd be glad to  
> hear, there's a better way to do it. It turned out to be a pretty  
> design problem; the crux is what to do when the user navigates to  card 
> *not* using the Back or Forward buttons. In that case I've opted  for 
> deleting everything in the list after the present "Ptr" position.  This 
> has the disadvantage of making some visited cards not accessible  
> through "Back". (Visit Able then Baker then Charlie, then go back to  
> Baker, then visit Delta. Charlie is not in the history path any  more.) 
> Getting around that requires, as far as I can see, adding  every visit 
> to every card (through a button or not) to the list, and  keeping a 
> potentially very complicated tree-based set of pointers to  it. The only 
> complete implementation of *that* kind of history I know  of is the 
> thorough, branch-preserving Undo facility of MOTU's Digital  Performer. 
> Certainly beyond me -- so it's a good thing it's beyond my  needs.
> 
> Charles
> 
> ======== handlers for script of stack to be "historicized"  
> =================
> 
> global gHistList, gHistPtr, gFromButton
> 
> on preOpenStack
>   put empty into gHistList
>   put 0 into gHistPtr
>   put false into gFromButton
> end preOpenStack
> 
> on backButton
>   if gHistPtr > 1 then
>     put true into gFromButton
>     subtract 1 from gHistPtr
>     put line gHistPtr of gHistList into tDest
>     go to tDest
>   end if
> end backButton
> 
> on forwardButton
>   put the number of lines of gHistList into tLast
>   if gHistPtr < tLast then
>     put true into gFromButton
>     add 1 to gHistPtr
>     put line gHistPtr of gHistList into tDest
>     go to tDest
>   end if
> end forwardButton
> 
> on preOpenCard
>   if not gFromButton then
>     repeat with n = the number of lines of gHistList down to  gHistPtr + 1
>       delete line n of gHistList
>     end repeat
>     put the name of this card & return after gHistList
>     add 1 to gHistPtr
>   end if
>   put false into gFromButton
>   if exists(btn "Back") then
>     disable btn "Back"
>     if gHistPtr > 1
>     then enable btn "Back"
>   end if
>   if exists(btn "Forward") then
>     disable btn "Forward"
>     if gHistPtr < the number of lines of gHistList
>     then enable btn "Forward"
>   end if
> end preOpenCard
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 
>