Geometry scaling problems

[massung]

I'm having a bit of trouble getting the behavior I want (using the automatic scaling w/ Geometry).

I have a field that pretty much takes up the entire stack view, and it's setup to scale in both the X and Y directions. And everything works just fine.

However, in a special mode, a group will be unhidden at the bottom of the stack and the rectangle for this field will change (so it doesn't overlap this group). This behavior similar to that of the find group in the script editor.

Now, when the group is visible and I (via script) modify the rectangle of the field, the automatic Geometry doesn't update along with it. It retains the old data, and the first time a resize message is sent, it resizes itself back to its original dimensions.

Is this a bug or is there a step I'm missing? I've tried the revCacheGeometry function, but this doesn't appear to do what I thought it did.

Obviously I could just override resizeStack or resizeControl and bash the rectangle with what it should be, but that's a last ditch resort, IMO.

Jeff M.

[Mark]

Hi Jeff,

I never use the Geometry Manager. There is always a point at which it goes completely bezirk. I'd recommend you write your own script that resizes the objects, dependingon whether the group is hidden or not.

Best,

Mark

[Bernard]

I'm with Mark on this. Unfortunately it is quite a lot of work to build a generic geometery manager (I know, it took me three attempts before I got mine working). Another problem with Rev's built-in GM is that there is no 'undo'. When I built mine I also built an undo feature that enables me to step back through each step to return controls to their previous positions.

At the very least, Rev's GM needs something like that. If you do use Rev's GM, and things go badly wrong, you have a lot of manual steps involved before you can return to a layout from where you can start to re-configure the layout.

I'm surprised there is not a huge outcry about the state of the GM. I'm only left with three possibilities: 1) the GM works but I don't get how to use it properly, 2) but most people don't want automated geometry management (regardless of whether Rev's GM works), 3) the GM doesn't work but most people are more patient than me and don't mind scripting geometry management on a per-control basis.

Unfortunately, my GM is not in any state that I could offer it to other people to use. I may try to work on documentation for it and make it public in the future. But given there is so little outcry about Rev's GM, I can't see there would be much interest in my code.

[SparkOut]

I use the GM quite extensively for the things I know it can do.
I also have a set of custom properties that I trigger on resizing, to "do" some manual positioning or scaling (especially in the case of tabstops on tablefield columns, where some "notes" columns expand, but the "date" columns, for example, stay fixed width).
Issues with the GM were the main difficulty I had in the trial period, and my first contact with Heather. I was working through a video tutorial and following on exactly, but getting different (non-working) results. Most of the time since then I have discovered a way around most of the issues. Generally if a stack works, then it works. Once a fault develops in the GM then it's toast for that card, so I make frequent backups. Having said that, I now find most of the toasting is caused by a single problematic setting, so maybe things are a bit better than they used to be, or maybe I'm just getting better at finding the issues.

[massung]

I had a lot of difficulties with the geometry manager until I realized that the radio buttons for position/scaling weren't mutually exclusive options, but just toggled between the two geometry "band-aid" views to let me set both. Once I discovered they worked in tandem, most of my issues went away. But there are still a couple problems. For the Rev team, I'd likely suggest the following changes:

1. Get rid of the radio buttons for position and scaling. Radio buttons implicitly mean 'choose 1' and mutually exclusive. Instead, use a tab view or another kind of control that implies both work together and you are just saving UI space.

2. I agree about undo. This is important.

3. The worst case situation for me is when I accidentally setup mutually recursive geometry between controls (X right scaling is bound to Y, Y's left position is bound to X). This causes serious problems during a resize. Detecting this and preventing it, or detecting that it's happened and removing the bindings would be very helpful.

4. Please let the GM go off the current position and size of an object, not just what it was set to in the inspector. Things can change at runtime.

Jeff M.

[FourthWorld]

I love the flexibility and robustness of writing my own resizeStack handlers.

Your layout can be accommodated in just a few lines:

Code: Select all

on resizeStack   x, y
  set the bottom of grp "SpecialMode" to y-20
  if the vis of grp "SpecialMode" is true then
    put the top of grp "SpecialMode" - 12 into tBottom
  else put y-20 into tBottom
  set the rect of fld "Main" to 20,20,x-20, tBottom
end resizeStack

Of course you'll want to modify that to use whatever margins you prefer, but the basic idea is simple enough.

And if you add other objects they can usually be handled in resizeStack with no more than one line per object. For that small price you get performance efficiency, robustness, and total control.