Steve,
you didn't specify whether you were going to summarize ideas or not, so you
can post this to the metacard list if you want.
Kevin,
Thanks for reply. The traffic on this list has been minimal so I'll
just post this. Maybe it will spark some more ideas.
Since you specified that you have many paths through a stack, I'll assume
that some paths overlap, that is include the same card. That means that
from card 1 you might go to card 3 or card 5 or card 2 depending on which
"presentation" you're doing. If not, and each card can only lead to one
other card, then having a "Next" button that leads to the next unique card
in the sequence would suffice. Your idea of having a field for each
presentation that contains a list of cards is the way to go.
For a single presentation I will be visiting the same card more than
once, but going in a different direction from there. Furthermore, I'm
not just staying in one stack! Even worse, some of the things I want
to happen aren't navigation related (i.e. click on a particular field
to sort it).
If your presentation won't be interrupted then you can have a single script
that sequences through the cards via a repeat loop. The loop can increment
through the cards on a mousedown (wait until the mouseClick), a time
interval (wait 5 seconds), or the user does some other action like touching
a key, moves the mouse to a certain location, or whatever.
I'm concerned about messages getting caught before they get to my
presentation script. The loop might solve that one.
If the presentation could be interrupted, then you have to have a global,
as you mentioned, to keep track of current presentation and sequence
location. However, this still allows you to have a generic "Next" button
that sends a message like "nextCardInSequence" which would be at the stack
level. Any event could send the "nextCardInSequence" message including a
"idle" handler that checks to see if a presentation is in progress and if
it is, then increments the cards based on time or user action criteria.
I would stay away from tying your function to a specific mouse button or
key that won't be apparent to the user. Also, any presentation "mode"
should have a method for cancelling the "mode" so the user doesn't get
caught in a loop.
One use of this capability is so that I can demo my stack. I will hold
the mouse like a slide project control and face the audience. I don't
want to even have to look at the screen. In that mode, there should be
no mouse movement required. Since I will be opening multiple stacks,
I can't just have a single stack button that does the work (because it
couldn't be in a convenient place). What I might do is put up a stack
that is like the "navigator" (the "presenter") but can also cause
messages to be sent to any control I like.
-Pothier-