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

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to