Reading a (BIG) text file one line at a time

[Richard Gaskin]

xbury.cs at clearstream.com wrote:
> 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