Palette as a stack or sub-stack, and a mouseUp/mouseStillDown question

[J. Landman Gay]

On 2/6/05 6:53 PM, Silver, Jason wrote:

> Up until now, I've had a stack "Screen", which is simulating the screens
> of our company's would-be handset.  When I first was playing around in
> Revolution, the stack contained a display and lots of buttons, much like
> a usual mobile phone.  However, to simplify screen creation, I made the
> stack "Screen" only 240x320 (the size of  the actual screen), so it
> would be easy to place icons and fields in exactly the same position as
> they would be on the real phone.  I thought that I would control the
> screen with particular keyboard presses (e.g. "S" for the Send key, "E"
> for the end key, etc.)

I did exactly this same kind of prototyping for a tractor dashboard for 
John Deere Company. Rev works just great for this. (As an aside: I was 
naive about tractors. When I thought of a tractor, I thought, you know, 
gearshift, a clutch, maybe a lever to raise a lift in the back. But no, 
today's tractors have control panels like spaceships; rows of controls 
and blinking lights in front of you, on the roof, at the sides. 
Back-mounted cameras. Computerized load sensing and wheel adjustment. 
It's Heinleinesque.)

Anyway, we too had both mouse-driven buttons and key press responses for 
everything on screen. When using keypresses, we made the buttons light 
up the same as when they were clicked on. It was good visual feedback.

> At this point, I think it's going to be easier to make buttons to
> navigate the interface, because we'd also like to be able to type into
> specific fields using the keyboard.  So, I've created a sub-stack called
> "Handset Buttons", and I've made it a palette.  Am I heading down the
> right road, or is it better to have the palette in a separate stack?

Substacks are better, it keeps all the parts together in the same file, 
and it is customary to store palettes that way.

If you want to avoid a palette, you can set things up so that keystrokes 
activate buttons when the cursor isn't in any field, but they do typing 
when a field is the target. Just examine "the selectedfield" in your 
script. If the selectedField is empty, then there is no field in use and 
you can send the keystroke on to a button instead.

> To give some context, once the user presses a button on the palette,
> such as "Send", the "Screen" stack will be jumping to a particular card
> (and this can change, depending on what field is highlighted on the
> current card).  Imagine highlighting an particular menu item on your
> mobile phone and pressing select; the next screen is entirely dependent
> on what line you're highlighting.  When I'm in fields on the "Screen"
> stack, how do I monitor which buttons are pressed on the "Handset
> Buttons" sub-stack?

Have you considered simulating the entire phone and putting the buttons 
on the bottom of the card? Then you can group them, set the group's 
backgroundbehavior to true, and every new card will share them. When you 
change cards, the bottom of the screen will remain the same, so it won't 
look like anything but the phone's "screen" has changed. Another plus 
with this technique is that you could use a custom window shape so your 
card window looks exactly like a phone floating on the monitor.

If you do decide to use a palette, then any button clicked on it will 
receive the mouseup message, and if it isn't handled, the message will 
go to the palette's card, stack, etc. Put mouseup handlers in the 
palette buttons, or in the palette card, and have them send messages to 
the main stack. There are a couple of ways to do that. You can use the 
"send" command to send a message to the mainstack:

  send "mycommand" to cd x of stack "myMain"

or you can set the defaultstack and just call handlers normally, like this:

set the defaultstack to "myMain"
doHandlerOne  -- this is a handler in the main stack


> The situation is further complicated by certain buttons I want to have
> on the palette that will do two different things, depending on whether
> you're short-pressing the button, or pressing and holding the button.
> It seems logical to have a long-press on the phone map to a
> "mouseStillDown" message in Revolution.  However, I want to make sure
> that when there's a long press of a button, that the "mouseUp" message
> is NOT sent afterwards.  So, the mouseUp of a button is the short-press,
> and the mouseStillDown is the long-press (that doesn't do the
> short-press as well).  Is this accomplish by message sending or passing?
> Or am I completely off-base?

I would use a mousedown handler to start a timer. Use a mouseup handler 
to stop the timer and compare the milliseconds from when the timer 
started. If the period of time is less than a certain amount, consider 
it a "short" press. Anything else would be a "long" press.

I wouldn't use mouseStillDown. I've found it somewhat unreliable, but 
even if it worked 100% of the time, the first "mouseStillDown" is sent 
so quickly after a "mousedown" that there is virtually no time 
difference. MouseStillDown then repeats over and over until the mouse 
goes up, so you'd have to figure out a timing mechanism anyway in order 
to figure out which presses were "long" ones. It's easier to just time 
every mouseDown-mouseUp pair.

> 
> Phew, I think that explains everything I'm dealing with at the moment.
> I wanted to thank all of you again for getting a newbie like myself off
> the ground with Revolution and the Transcript language.  Your help has
> proven invaluable!

We "pay forward" here. Someday we will get you back. ;)


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com