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 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
