LiveCode Forums.

I'm trying to figure out how to place limits on the aspect ratio of a stack, when the user resizes it. I'd like it to be limited to something between 4:3 and 16:9. I'd like it to accomplish this by reducing the height or the width in order to stay within the limits.

I've tried all sorts of stuff in the resizeStack handler. The thing that comes closest to working is to set the height or width, if the ratio is out of range. But if I maximize the window on a screen that has an 8:5 aspect ratio, which is within the limits, it ends up smaller than the screen in both dimensions, no matter what dimensions the window has before maximizing it. Also, I'd expect doing that to recursively call resizeStack, but it doesn't seem to.

I've also called revChangeWindowSize inside resizeStack, but that does ugly stuff. And I've tried dynamically manipulating maxHeight and maxWidth.

Is there any other way to do this?

Hi.

I have not played with this, but surely you can (assuming you have a fld 1): And with the final rect, you can do the math and resize the stack to the ratio you want, including fitting as best as you can into the screenrect.

So is the issue that there is no "reSizeStackEnd" message, that is, you cannot do something automatically when the user is finished with the resize action, because there is no message sent when the action is done? In other words, there is no analog to the "dragEnd" message, for example?

We can do anything, as long as inelegance is not a factor. Write back...

Craig Newman

Hi All,

there is no "reSizeStackEnd" message

Bernd did one :
Best regards
Jean-Marc

Operating systems make it easy to handle the contents of a window however you like, but make it harder to introduce non-standard behavior for the window itself.

I've also found that users sometimes use windows for proposes beyond just viewing the content we put in them, such as maximizing them to cover things they find distracting while using an app.

Would simply constraining the contents of the window, leaving the user in control of the window itself, be an option?

Bernd did one

I would not characterize that as "inelegant".

That is what I meant, that there are secret pathways within LC to ferret out such gadgetry.

But, pderocco, is that the issue? To determine when the user has stopped resizing, and get LC to take over?

Craig

Something doesn't work here, and I don't quite know why:

on resizeStack NW, NH
put the round of (NW/16) into F1
put (F1*9) into NewH
set the height of me to NewH
pass resizeStack
end resizeStack

I suspect that the "set the width of me to NewH" tips the thing into an endless loop.

This works with no obvious problems if one changes the WIDTH of the stack:

Global NewH

on resizeStack
send "mouseDown" to me
end resizeStack

on mouseDown
put the width of me into NW
put the round of (NW/16) into F1
put (F1*9) into NewH
set the height of me to NewH
end mouseDown

Well, it isn't perfect, but it is a lot simpler than all the stuff above:

in the stackScript:

on resizeStack
send "mouseDown" to me
send "mouseUp" to me
pass resizeStack
end resizeStack

on mouseDown
put the width of me into NW
put the round of (NW/16) into F1
put (F1*9) into NewH
set the height of me to NewH
end mouseDown

on mouseUp
put the height of me into NH
put the round of (NH/9) into F2
put (F2*16) into NewW
set the width of me to NewW
end mouseUp

At this point, I'm not interested in having LiveCode fix the aspect ratio when I release the mouse button, because I'm hoping I can get everything inside the window to resize dynamically as I drag, and I don't want it to resize into something really ugly even if temporary. So I'm not looking for a way to detect when it's done resizing.

What I was hoping for was access to what in Windows is called the WM_SIZING message. The OS tells the app "I want to resize to w*h" and the app can ignore it, or can respond with changed w or h. I assume every OS windowing system has some protocol like that.

I created two empty apps and exported them for Windows, Mac, and Linux. The first, aspect-by-set, is an empty stack with the following stack script: The second, aspect-by-max, is an empty stack with the following stack script: On Windows, aspect-by-set works, but as soon as you try to exceed the aspect ratio, you get flicker as it draws the erroneous border and then erases it. This is tolerable, but looks ugly. (Before, I was having a problem with maximizing it not filling the screen, but that was only because I was running under the IDE, and didn't realize that the IDE redefines "maximizing" to the portion of the screen below the main IDE window. There are a lot of weird, obnoxious things that the IDE does. But this goes away when you build a standalone.) On Windows, aspect-by-max doesn't flicker, but the resize mechanism only reads maxWidth and maxHeight once at the beginning of the drag, and doesn't notice the changes taking place during the drag, so you can only increase the size of the window a little at a time, alternating between horizontal and vertical.

On the Mac, aspect-by-set places no limits on resizing, but if you stretch it too wide or tall, and then move the window around, after a couple of seconds, it notices the error and snaps one dimension back to correct the aspect ratio. This is unusable. On the Mac, aspect-by-max works exactly the way I want it to when I drag, but when I maximize, it naturally only enlarges the window a little.

On Ubuntu Linux, aspect-by-set works just like it does in Windows, with the same ugly but tolerable flicker. On Linux, aspect-by-max works almost the way it does in Windows, but sometimes it's hard to get it to allow me to enlarge the window at all, and I have to really fight with it.

So at this point, I don't see how to get this to work at all on the Mac. I wish that aspect-by-max worked like on the Mac, but there was some other way to temporarily enlarge the limits before a maximize operation takes place.

I may have to abandon the idea of dynamically resizing everything during the drag, and just let it clip everything when reducing the window size, or filling the right and bottom with background color when enlarging it, and then redrawing everything with a new corrected size when the resize is complete, maybe using Jean-Marc's technique.

aspect-by-max

?

Presumably this means you want the stack to be the same size as the screenRect.

Hi friends,

the trick is NOT to use the "resizestack" message for this, but rather roll your own!
The "resizestack" message cannot be overwritten in real-time, as you already have experienced.

Do this:
1. UNcheck "resizable" for your stack
2. Go to -> Menu: Development: Object library
3. Select "Mac or Win style stack resizer"
4. Place that object in the lower right corner in your stack and then
5. Open its script, read it, let it inspire you and then modify as neccessary.

Best

Klaus

richmond62 wrote: ↑

Tue Sep 18, 2018 8:32 am

aspect-by-max
Presumably this means you want the stack to be the same size as the screenRect.

Are you asking about my choice of name? It just means "constrain the aspect ratio by setting maxWidth or maxHeight".

As to screenRect, that's the size of the whole screen. Even when a window is maximized, it is still set to something less than that, to allow for the borders and the title bar.

it is still set to something less than that, to allow for the borders and the title bar.

That is problematic as LiveCode is not very good at "seeing" all the "desktop furniture"
(docks, taskbars, menubars, XFCE panels and so on) that desktop GUI systems offer.

Hm, looks like noone is actually interested in the solution.

Well, at least one of the

noone

has spent the last 3 days painting walls
and mounting whiteboards and so on walls as his EFL school was badly in need of
redecoration before the new school year.

That person will be looking at ONE of a number of possible solutions shortly.

the solution

Just a peerie bit dogmatic, forbye.