While I did write a bunch of stacks with their own GM, These have been
hard to maintain. No matter how simple you make them, as soon as you
have two panes interacting, the script becomes twice as hard. Add two
fields that overlap or hide and multiply by 4. Yes, some parts can be grouped into smaller handlers. But not all...
Add in the second pane a bunch of tabbed groups with each their own
panes or double panes and your scripts are going to be geometrically harder and harder to do.
I tried the group GM delegated independent scripts. Problem however came
when you would call teh resizestack and the group or card wouldn't find it!
You might give it another whirl.
I've been revising the UI for ResearchWare's HyperRESEARCH application, consolidating multiple windows into a more manageable single window with multiple pane, a la Outlook or Mozilla's email UI (and since Mac OS now interleaves windows like all other OSes, I suspect many other developers are also migrating multi-window UIs to a single-window design).
Like you, I found that managing everything in a single script was cumbersome, so I broke it up so that each pane (group) is now responsible for its own resizing.
My stack script responds to the resizeStack message by updating its controls that are not in any of these panes, and then sends a ResizePane message to each of the "pane" groups so they can do what they need for their own contents.
One advantage to breaking it up like this is that the divider controls between panes often affect no more than two panes, so the handlers there send the ResizePane message only to affected groups without bothering the unaffected ones.
While "send" is measurably slower than anything natively in the message path, remember that Transcript isn't like most other xTalks: the difference is measurable but not noticeable, with an overhead of about 0.003ms per "send" (on 1GHz single processor G4 PB -- there's a test already in RevBench for that, on card 5).
If you turn on the backgroundBehavior of the groups to put them natively into the message path to get the resizeStack message directly, the very modest time savings is offset by the overhead of needing to keep track of the firing order (the groups' layers), and all groups will always get the message, which may not always be what's needed. Since I use an explicit "send" I retain control over the order of execution and am free relayer groups as I may need for other purposes.
...
BTW, the bug is still unconfirmed...
It was posted less than two weeks ago. I've gotten a lot of cc's of fixed bugs in the last week, so I know they're working rapidly through the list. I'm sure they'll get to that one soon enough.
-- Richard Gaskin Fourth World Media Corporation __________________________________________________ Rev tools and more: http://www.fourthworld.com/rev
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
