Re: Setting Geometry Manager Properties For A Stack
Mikey- As usual, the answer is so simple. I am completely brain-mashed from too many years of tools that aren't so reasonable. rotfl. I know that feeling well. -- Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Setting Geometry Manager Properties For A Stack
Mikey wrote: I'm trying to limit a stack from being resized smaller beyond a particular point. Mikey, You can set the minwidth and minheight properties of the stack in the property inspector - size and position pane. Martin Baxter -- I am Not a Number, I am a free NaN ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Setting Geometry Manager Properties For A Stack
On 6/23/08 2:25 PM, Mikey [EMAIL PROTECTED] wrote: I'm trying to limit a stack from being resized smaller beyond a particular point. I've got all the objects on the stack resizing or moving the way I'd like them to, but I'd like to keep the user from making the stack too small to the point where the controls on the right and toward the bottom are gone because there isn't room to display them. I've tried applying limits to the objects on the stack, but that doesn't seem to do it, rather that seems to just maintain the geometry and position of the objects relative to the stack window size. How about setting the 'maxHeight' and 'maxWIdth' of the stack? Ken Ray Sons of Thunder Software, Inc. Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Setting Geometry Manager Properties For A Stack
As usual, the answer is so simple. I am completely brain-mashed from too many years of tools that aren't so reasonable. -- Arnold Schwarzenegger - I have a love interest in every one of my films - a gun. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The Geometry Manager
On 11/27/04 12:32 PM, Geoff Canyon [EMAIL PROTECTED] wrote: On Nov 23, 2004, at 7:58 AM, Richard Gaskin wrote: 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 Richard, I've long thought that an inherent weakness in the current design of the Geometry Manager is that it doesn't take into account the sequence in which things are resized. That's not to say that it isn't useful, just that there are inherent limitations. I think your post, cited above, makes clear what the more powerful setup would be. It seems to me that an interface for specifying a sequence of steps such as your method performs would be fairly simple to produce, but also largely unnecessary, in that it wouldn't be much easier to create/maintain than the simple list of statements you use. I think what Xavier wants is something else again: a Geometry manager that functions sequentially as your method does, but also involves conditionals. If item x is less than y pixels wide, hide item x and proceed down this different path. That's beyond the scope of either the current GM or the simple interface to your sequential method above. Agreed. One nice thing about code is it has its own inherent sequencing - you do line 1 first, then 2, etc. until you're done. This way, when you set up your resizing/adjusting you put it down in the firing order you want. My method is slightly more compact than Richard's, but it does the same thing. I'll use conditionals as necessary, especially to restrict the resizing of an object (for example, if the user is resizing a stack and I want an object to have a minimum size, I will resize that object first, checking to make sure it doesn't go below its minimum, and then will resize the other objects accordingly. All of which is to say that I think the only reasonable way to handle a complex geometry involving showing/hiding objects and conditionally resizing others is by code. I can't imagine an interface that would clearly and simply allow you to specify that. The only one I can imagine would be one that laid down steps in a list that it would follow, but it would just be a more readable version than what you'd do in code. For example, you might have this in code: ObjRect the long id of fld 1, ,,x-200,y-20 ObjRect the long id of fld 2, the left of fld 1,,x-20,y-20 but in an interface it might be multicolumn and show: OBJECT ADJUSTMENTS RELATIVE TO field FirstField Rt: -200, Bot: -20 Stack field SecondField Left: Match field FirstField field SecondField Rt: -20, Bot: -20 Stack But either way, it wouldn't be visual... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: The Geometry Manager
Actually my idea of the ideal GM was a turing machine like contraption! The script was never written but its design was pretty close to RunRevs. The GUI too but had a bit more detail. and some missing features... The script was never done since I got RunRev just as I finished the GUI. Their design is pretty good apart from a stuut as they say in Brussels. There's a GUI for it in the ControlsBrowser on MonsieurX. It's a hidden tab in the lower part of the palette. Just add a tab named Geometry to the content button's and then do the right swaps to get it in view. (It might have moved a bit off in relation to the splitter bar due to GM problems and not being readjusted lately - minor priority.) X -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Canyon Sent: Saturday, November 27, 2004 19:33 To: How to use Revolution Subject: The Geometry Manager On Nov 23, 2004, at 7:58 AM, Richard Gaskin wrote: 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 Richard, I've long thought that an inherent weakness in the current design of the Geometry Manager is that it doesn't take into account the sequence in which things are resized. That's not to say that it isn't useful, just that there are inherent limitations. I think your post, cited above, makes clear what the more powerful setup would be. It seems to me that an interface for specifying a sequence of steps such as your method performs would be fairly simple to produce, but also largely unnecessary, in that it wouldn't be much easier to create/maintain than the simple list of statements you use. I think what Xavier wants is something else again: a Geometry manager that functions sequentially as your method does, but also involves conditionals. If item x is less than y pixels wide, hide item x and proceed down this different path. That's beyond the scope of either the current GM or the simple interface to your sequential method above. Conditionals are hard to represent graphically. It makes more sense to handle them in code. Your (Richard's) method, at one line per element resized, is about as compact as possible. All of which is to say that I think the only reasonable way to handle a complex geometry involving showing/hiding objects and conditionally resizing others is by code. I can't imagine an interface that would clearly and simply allow you to specify that. regards, Geoff Canyon [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re[2]: geometry manager
Hi, Helps a lot , thanks ! works again. will think of upgrading to 2.5 after the release of Version 2 of my product xccc 2.1 has a few GM bugs... xccc Not that 2.5 isnt bug free but it is (ahem) better behaved. xccc My guess is that an old position got stuck or didn't get updated xccc because some event blocked the update. This can happen when you xccc have a pending error, self-resizing stack or a resizestack handler that xccc doesn't pass resizestack or send revUpdateGeometry back. xccc Try to send a revUpdateGeometry to your stack to see if it gets fixed. xccc If not, clear the revgeomtry settings for your control, and then xccc reassign the GM rules. This usually fixes the problem... xccc In some cases, you can put an empty resizestack handler to block the xccc GeomtryManager, resize your stack/controls and then remove the blocking xccc handler. Doesn't always work though but it's one way to fix it. xccc Hope that helps ya xccc Xa have some problems with the geometry manager... works fine for few days, but this morning, few objects where out of the window, and now when i'm changing the size of the window ( drag bottom-right ), one field systematicaly move few pixels too much to the right ? which it didn't do before ? Does the geometry manager being stable and quite reliable ? PC Win98 Rev 2.1. work with one group and 2 fields ! Best regards, ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
