Avoiding mouse polls

Dar Scott dsc at swcp.com
Sun Dec 15 16:23:01 EST 2002

Some thoughts came to my mind.  Yes, they all involve send.

If buttons that can arm are suitable representations, then maybe one of 
these can work.

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.

Maybe there is something that can work with tabs.

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