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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
