Avoiding mouse polls
Dar Scott
dsc at swcp.com
Sun Dec 15 11:23:01 EST 2002
Some thoughts came to my mind. Yes, they all involve send.
1.
If buttons that can arm are suitable representations, then maybe one of
these can work.
1.A
This might make development easier (after the initial work).
If mouseLoc() can arm a button, then a card or stack send-cycle engine
can move the mouse pointer over each button in sequence causing it to
become armed (with either a border or an arm image). The mouse might be
invisible. This allows the entire app to be developed and tested with a
regular mouse. The switch capability might be controlled during
development and testing with three function keys to set it to Off, Debug
and On. (Debug might set the cursor to a plus; On might set it to
something invisible. It may be possible to have a generic send-cycle at
the stack level that cycles through all enabled buttons with autoarm set
in layer order. For cards where that is not suitable, that can be
intercepted at the card level.
1.B
Maybe there is something that can work with tabs.
2
My wildest idea, one of those shower things, is this. (Maybe this is
how "everybody" does it and I didn't know.) Put a ball on a wire track
or a train engine on a train track. Create images or buttons that can
be tiled to set up the functionality of a card and to create the track.
Each track section uses send in 0 to pass the ball to the next tile.
Tile pieces might be these:
Vertical section
Horizontal section
Curve (4)
Vertical button (toggle, single, momentary)
Horizontal button (as above)
Track Switch (8)
Tunnel (in/out: 4 directions)
Edit Tunnels (in/out: fields, popup...)
(button to switch connections?)
The control zone of any card can be made up of these. "Programming the
card gui is simply placing tiles. Well, a big part is. Maybe this can
be made an overlay over existing cards. (I have no idea how suitable
any of this would really be.)
Dar Scott
More information about the use-livecode
mailing list