How to "re-resize" Stack (elements)

[redfield]

Hi guys,

not sure if the subject makes sense, I would like to resize the Stack and all the elements (fields, etc.) on its Card. I have set maximum and minimum width and height values in the property inspector. So let's say I decrease the window size, the size of all elements needs to be decreased too. I think this could be achieved by something like:

Code: Select all

on resizeStack newWidth, newHeight
   lock screen
   set the width of graphic id "1600" to newWidth -10

However if I want to revert the change, grab the corner of the window and make it bigger, how do I get the elements to "grow" back to their original size?

[dunbarx]

Hi.

Are your resizing under script control or manually? It sounds like manually.

The "resizeStack" message will track the current size of your stack as you drag a corner. That message will continue until you finish the drag. The trick is to get the initial rect and store it somewhere, so that you can figure out the old size as compared with the new.

Once you have that you can scale all the controls on the card, or on all the cards, keeping their locs intact.

Here is a stack to play with. It needs something better to set the current stack size just before you grab a corner and resize. Right now you must click on the card window sometime to lock the current size. I had trouble with this because messages such as "mouseDown" are not set when the cursor is in the area where resizing is available.

reSize.livecode.zip

(1.5 KiB) Downloaded 84 times

Anyway, click somewhere, grab a corner and go. The ratio of old to new appears in the lower field. From there you can play with your controls.

Craig

[Klaus]

Important hint from LC:
Do NOT "lock screen" during a "resizestack" handler!

[stam]

Important hint from LC:
Do NOT "lock screen" during a "resizestack" handler!

Thanks for the tip Klaus - i'm almost certain i have locked screen in some resize handler or other but never experienced ill effects... what's the reason no to do this?

regards
Stam

[Klaus]

From the dictionary, looks I had this not correctly in mind, so maybe my warning was a bit too much:

...
The screen is locked while a resizeStack handler is running, so it is not necessary to use the lock screen command
to prevent changes from being seen. (However, the lockScreen property is not set to true.)
...

[redfield]

This has helped me in so far as I realize that the resizeStack handler has four parameters and not only two. However I'm not really making progress and it looks like I will produce hundreds of lines of code for the resizing. Is there a common way in Livecode to adjust windows (and their contents) of Desktop apps, according to the screen size?

[stam]

You can adjust size and location of controls with the geometry manager.
It works well but can be a bit buggy. I use this all the time as have hundreds is controls on some cards.

Basically if an error occurs during resize (eg if a GM constraint is is a missing control or if there is some other error) it crashes silently with no warning to the developer and resizes and repositions controls crazily off screen.

There is a lesson on the GM - have a look at that.
In addition worth knowing two commands to run in the message box:
- revCacheGeometry true — run this every significant layout change
- revUpdateGeometry — before resizing the stack run this in the message box. If there is an error then review all GM rules and fix these to avoid crazy errors. Also put this in the preOpenCard handlers and a change in size in one card doesn’t automatically propagate to other cards.

[SparkOut]

I was going to say what stam said ^
The Geometry Manager is not terribly well respected but if you pay attention to what stam mentioned you should not have too many problems.
Judicious use of revCacheGeometry is helpful, and significant, but it is not always clear what is going wrong if something goes wrong, and if it does then it will go wrong totally, so get used to taking lots of backups.
I use the GM and find it pretty ok "on the whole". Look up previous threads to see useful discussions on the subject, especially the one with the revCacheGeometry revelation.
If you code your own, in the manner you first mentioned, your first code will work to expand as well as shrink, relative to the new stack size. Lots of users code their own resize handlers like this, relative to the "new" stack size (but for all the mud-slinging, the GM can do what you need). You can do many and various things to create a "framework" of your own though, such as setting a custom property on each control you want to scale, with some detail about the margin or width/height that you want it to have relative to the stack or another object. Then in your resize handler that loops through all the controls on a card and check for the custom property to taken action for appropriate scaling. (You don't need hundreds of lines, but you do need to plan.)

[stam]

Yep, i do that too.
For example - in fields where i want to resize text depending on available field size, i assign behaviour to these field that does the text resizing.
These fields have some custom properties (eg minTextSize, maxTextSize, isResizeable) and a handler fires off looping through all fields and doing the resizing if the boolean isResizeable is true, constraining the text sizes between min and max set for each such field.

However, i was bitten but a slight bug (or, if you like a bit of info that wasn't in the documentation): If you're going to resize the controls with the GeometryManager and use code in resizeStack as well, the first thing you should call in resizeStack is revUpdateGeometry to ensure the resizing of controls by the GM is done *before* any other code runs.

And i can't stress enough that you should save prior to resizing and ensure revUpdateGeomtry (run from the msg box) doesn't generate an error before doing any of this... or you will spend an uncomfortable amount of time putting controls back the way they were...

[redfield]

Thanks guys, I will look into the GM. I was a little naive about how big a job this will be

[FourthWorld]

Thanks guys, I will look into the GM. I was a little naive about how big a job this will be

Maybe. There may be ways to use groups well to cut down on the coding. Can't say without seeing the interface, but having scripted resizing windows since my first contract in '89 I've found most take a few minutes, super complex ones may take an hour, and in all my life I've seen only one UI that took a day (though that was before a lot of engine additions that make handling resizeStack much easier).

[dunbarx]

Richard.

89???

I thought you were an old-timer.

Craig

[FourthWorld]

Richard.

89???

I thought you were an old-timer.

I prefer the local East LA moniker "veterano".

I had done some small contract work with HyperCard, but for me serious work began with the release of SuperCard in June 1989. Later that year I was hired to make a prototype of a new tomography technique as part of a research grant under SBIR for the US Department of Energy. Been delivering apps in xTalks every year since.

[jacque]

I've found most take a few minutes, super complex ones may take an hour, and in all my life I've seen only one UI that took a day (though that was before a lot of engine additions that make handling resizeStack much easier).

Have you ever had to resize a stack with hundreds of controls? The main reason I try to switch to automatic resizing whenever possible is the amount of time it takes to resize and reposition every control in every stack. I've done it in the past but I find it so tedious that I hired someone else to do it for me, and it took him much longer than an hour.

I know manual resizing can be more accurate in some circumstances. Can you share some tricks that would help convince me it's worthwhile? I don't think I've ever seen your method, though I vaguely remember your setRect handler.

[FourthWorld]

We've had this conversation a lot, Jacque. And we've always agreed on the best way to handle every case where we've seen the UI and understand the design and business goals.

If you have a new work we haven't discussed that you'd like some help with let me know,
I'd be happy to see what I can do.

Same goes for the OP here, as I've done here before: if the UI stack can be posted we can can offer more specific guidance.