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

[xbury.cs at clearstream.com]

Thanks Richard. Indeed it was 2341... I typed at 6:30 and was still a bit
pillow headed when I typed that... 

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!

Dont ask me, it would do this - maybe reverrordisplay blocking things but
I spend a lot of time adjusting this or that scritp for a one pixel offset 
to look
good and design worthy and day after day, the time adds up.

When I bought the RunRev IDE, all my stacks took a 1/2 to 1/4 of the time 
to 
finish thanks to the GM! That's right! It takes a long time to make some 
GM work in
complex GUIs but not with the RunRev GM!

So I was quite happy to delete my resize scripts and all the group 
resizegroup
scripts that took so long to edit, or change... Click, click, done...

I must now admit I love the GM! But this little bug is definitely grown 
into a
major problem because I didn't realize the implications - not much about 
the 
GM is explained, let alone what not to do. 

So for simple stacks and even low-medium complex guis, you're absolutely
right and you script might be handy despite being Much much slower than 
using
the revPropertyPalette. 

But the Discrete browser is become a beast with fields that hide or not,
resizable multi-panes in resizable panes...

And the problem is not the complexity of the stack. It's the 
revCacheGeometry
which doesn't really reset the GM props as you see them when you call 
revCacheGeo.

This is normal if the related controls have changed ids because you 
cut-pasted
them into a group. What is not normal is that reseting the props doesn't 
help after
this happens once. I checked that the cprops were gone. Re-inputed all the
control relations in GM editor and bam, again, gone wrong at the first 
move - if it
resizes at all. That's illogical!

So for 2 stacks where geometry would mean a whole lot of development time 
(about a week two two weeks - all my past time for the controlsbrowser 
stack and
 the discretebrowser (over 500 controls with the two stacks involved ) and 
back to 
double the daily development time that RunRev saves me...

Not very economical or effective imoho... I wont reinvent the wheel and 
feel like a 
cromagnon and get the worst of all cases again...

But I will check you link more in depth and see if that's xos'able... It 
certainly is in 
the right direction at first sight. However my goal is not to replace 
features in runrev 
but to add power to them and leverage the features in RunRev to make a RAD 
even
faster! 

Anyway, I've burned out this issue to the point that Im scared to 
resizestacks, that i dont
want to see those two stacks at all! I really dont care to think about 
them for the next few
months. Maybe some user feedback will help.

BTW, the bug is still unconfirmed... 

Thanks for your vote for
http://support.runrev.com/bugdatabase/show_bug.cgi?id=2341

On 23.11.2004 16:58:26 use-revolution-bounces wrote:
>MisterX wrote:
>> Unfortunately, all my development is blocked by bug 2431. If you vote 
for
>> it, I will make this stack available again tonite.
>
>Searching for "2431" in Bugzilla returns "Bug 2431 does not exist."
>
>Did you mean #2341?  If so, it needn't be a show-stopper:  while the
>Geometry Manager is a nice convenience it's by no means essential.
>Since long before the GM existed the engine has provided a resizeStack
>message which can be trapped directly to handle your layout needs.  It
>is that message that Rev's GM script itself responds to in order to do
>its stuff.
>
>While the GM is handy for many layouts, if you have a circumstance it
>doesn't handle gracefully yet I suspect it would take only a few minutes
>to write your own resizeStack handler that will do what you need.  As
>highly generalized code, the GM does a lot of extra work in order to
>provide its conveniences (the script is about 40+k last time I checked),
>so your custom resizeStack handler will likely provide better
>performance as well (though the engine is so fast the difference may not
>be noticeable).
>
>One of the complexities in generalizing layout adjustments is, as you've
>identified in your report, getting the firing order correct:  if you
>have objects that are placed relative to other objects, you need to make
>sure some objects are adjusted before others.  While the GM does a
>pretty good job at that most of the time, doing it perfectly for all
>possible layouts requires something that approaches AI, but with a
>custom resizeStack handler you retain total control over the order in
>which things happen.
>
>You can save yourself some typing by reducing the number of lines in a
>resizeStack handler with something like the handy ObjRect handler
>described in this link, so at most you'd have only one line per resized
>object:
><http://lists.runrev.com/pipermail/use-revolution/2004-January/029978.html>
>
>Thus far the most complex layout I've scripted a resizeStack handler for
>took about an hour; most take less than five minutes.  At one line per
>resized object, typing a resizeStack handler often takes no longer than
>setting properties for the GM.
>
>But even if it took longer, I suspect the time required would be far
>less than even the shortest turnaround anyone could reasonably expect
>for that bug fix.  So while the bug should indeed be fixed, there's
>certainly no need to stop development waiting for it.
>
>Carpe diem.

-----------------------------------------
Visit us at http://www.clearstream.com
IMPORTANT MESSAGE    Internet communications are not secure and therefore
Clearstream International does not accept legal responsibility for the
contents of this message.    The information contained in this e-mail is
confidential and may be legally privileged. It is intended solely for the
addressee. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful. Any views expressed in this e-mail are
those of the individual sender, except where the sender specifically states
them to be the views of Clearstream International or of any of its
affiliates or subsidiaries.    END OF DISCLAIMER