LiveCode Forums.

It is the Geometry Manager . . . Hence the problems.

Is there a way to disable the Geometry Manager?

richmond62 wrote: Thu Feb 10, 2022 8:37 pm Is there a way to disable the Geometry Manager?

I could just not use the GM - but then I’d have to add significant amount of code to move/resize a huge number of graphics, groups, fields and so on. The GM is a great timesaver and I’d really loathe to stop using it… so for me that’s not the answer.

Bernd has kindly given provided a workaround for the issue with fullScreen anyway…

Hi Stam,

It bugged me to use the send in time hack.

Here is a version of your stack script that does not need this. It invokes the GeometryManager explicitely _before_ setting the textSize of the field
I do agree with you that for example a lesson would be helpful to explain the intricacies of using the GeometryManager. And while writing this I wanted to make sure what the "User Guide" is saying about GM and searching the User Guide for "Geometry" turns up on page 59 (LC 9.6.6) a short description.
It also mentions the use of "revUpdateGeometry" if you want to force the GM to kick in.

I probably would not pass "resizestack" at the end of the handler because the GM is already done.

Kind regards
Bernd

Bernd you are a true genius
not only is this more palatable syntactically but actually the resizing is a whole lot smoother!

I do use revUpdateGeometry on all preOpenCard handlers, otherwise change in stack size while on one card does not automatically update other cards.
Given this advice and the immediate improvement i've seen, i'll be calling revUpdateGeometry in resizeStack on all cards that use GM as well...

Thank you!

stam wrote: Fri Feb 11, 2022 11:10 am Bernd you are a true genius

I would'nt go that far...
But my professional ethics command helping a colleague

Kind regards
Bernd

stam wrote: Thu Feb 10, 2022 10:00 pm I could just not use the GM - but then I’d have to add significant amount of code to move/resize a huge number of graphics, groups, fields and so on. The GM is a great timesaver and I’d really loathe to stop using it… so for me that’s not the answer.

Given the initial time to click click click click click click plus this thread now spanning three pages, how much time was saved?

The GM itself relies on the resizeStack message. By handing it myself directly I not only get smoother performance by bypassing generalization (the only code invoked is the only code needed), but more importantly have complete control over exactly how the layout is handled.

And given that the resizeStack message has been around since 1992 but the GM scripted subsystem was added on top of it more than a decade later, the additional vetting of the resizeStack message has meant that I'm never surprised by outcomes using it directly.

If using resizeStack directly ever becomes an interest for you, feel free to post example layouts and we can discuss lean direct solutions. In every case we've done that in these forums so far, the amount of code needed in the end has always been far less than what was anticipated.

FourthWorld wrote: Fri Feb 11, 2022 5:21 pm If using resizeStack directly ever becomes an interest for you, feel free to post example layouts and we can discuss lean direct solutions. In every case we've done that in these forums so far, the amount of code needed in the end has always been far less than what was anticipated.

Thanks Richard, i get what you're saying - but in truth 'click-click-click' is a whole lot quicker than writing adding, maintaining and subtracting code. The fact that this, as you say, spans three pages is the fault of missing documentation, not because of a problem with the GM per se. Given that the GM is an integral component of the IDE my view is that the final solution here should have been mentioned in the resizeStack documentation (literally just 1 line added).

In my particular case, this wasto resize and reposition about 16 fields and 8-12 buttons, 2 data grids. Some controls need to stay centred or in a relatively stable position when moving/expanding, some of which will both resize and reposition. And that's just 1 card.
While it's a complex build, i keep the look clean by hiding a number of these under tab-style controls so it's not remotely as busy as it sounds.

I can't see how this wouldn't be a lot of code - and when something breaks that's just more code to debug (not to mention coming back to it in a year's time). But it takes 2 seconds to adjust the GM for each control as I add it (since i'm usually in the property panel anyway) and then it's done.


Would you ever consider adding all your buttons and fields for every layout in code? I suspect not, even though you would have very fine control over positioning. Graphical layout is appealing to many for a reason and for me this is an extension of the graphical layout.

I'm used to this type of system from other platforms and just because it can be wonky, I don't see why we should throw out the baby with the bathwater!
Rather, i'd prefer to highlight issues so they can be fixed (or at least i can learn what i'm doing wrong!) - hence this discussion. And a clear solution was found.
All that is missing really is for this to be clarified in the documentation (adding a line to the resizeStack documentation is all that is needed).

Each to his own. For simpler projects i would not hesitate to use resizeStack and do use it generously - just not so much for resizing/repositioning as i prefer the graphical way of doing that.

But that's me and I know for some on this forum i'm a heathen - but i do like the GM

I offer no opinion here on how things should be.

I merely offer to lend my 30 years of experience scripting layouts for resizable windows based on what is.

How things should be . . .

A bottomless pit with no way out; possibly entertainment
over a pipe in my dotage, but not yet.

Things are as they are, not what they should be.

3 glasses of Bulgarian Mavrud.

richmond62 wrote: Fri Feb 11, 2022 8:29 pm Things are as they are, not what they should be.

Wise words…
But no harm in pushing for how you think they should be!

In my office should be goes in bug reports; is goes in shipping code.

There are many paths up the mountain.
Many details are not shown on maps.
When I see a fellow hiker struggling
with loose stone underfoot,
I tell them where I've seen
clear paths of solid granite,
sure-footed routes I know in my bones
because I've walked them.
They can ignore the guidance,
or argue against it,
but the paths remain as they are,
unaffected by words
of how they might be
if only...

Stam, I'm curious how you use the GM. I've avoided it because it requires a redo if the layout changes during development. Do you wait until the end of development to set it up?

I'm not fond of scripting layouts if there are a lot of controls, though I do sometimes if there are only a few. I find it tedious and time consuming and in some cases fullscreenmode works well enough. The last time I needed to script placement I subcontracted to someone else because there was just so much of it.

Richard, you've often said your method is easy and quick. I'd love to see an example of that. For me, it's never quick, it's a pain in the patoot. If a stack has dozens or hundreds of controls over many cards my heart just sinks.

jacque wrote: Sat Feb 12, 2022 6:58 pm Stam, I'm curious how you use the GM. I've avoided it because it requires a redo if the layout changes during development. Do you wait until the end of development to set it up?

No you don't need to wait until the end of developement- just run revCacheGeometry true in the message box after any change to the layout and it will update the GM so it doesn't misbehave. This was the advice from Brian Milby in a long, heated thread and i've found this to solve > 95% of issues.

I generally start from small or average size stack and lay out some controls as desired - this will usually represent the smallest size stack i'll allow (so that controls don't overlap if shrunk further). I then just quickly assign the desired GM rules to each control and when done i just run revCacheGeometry true in the message box. I also do this any time i add controls and generally with any significant changes to the layout. Probably placebo beyond a certain point but it keeps the ghoulies away....
No issues combining both resize and move rules but some logical issues can occur (eg if you link to a control that no longer exists - and you'll get no warning about this -- see below).

In every card's preOpenCard handler i add revUpdateGeometry as when you change stack size when on one card, it doesn't seem to update other cards. I also run revUpdateGeometry in the message box after layout changes (generally after running revCacheGeometry) as that's the only way you'll know if there is something funky with the GM rules (see below).
And, now following Bernd's excellent advice, i run revUpdateGeometry in the resizeStack handler if i have other code there. If anything, resizing is a *lot* smoother than sending a command in time to run such code.

Generally this will work exactly as intended. The only issue i have is if something crashes during resizing, the GM can malfunction and reposition everything in crazy places (off screen, a real pain) - thankfully this is rare if you use revCacheGeometry frequently - but i will save frequently whenever i'm changing resizeStack code or GM stuff *before resizing* just in case and not save again until i'm happy i haven't broken something
But once behaviour is stable i don't have any further issues and certainly in standalones this has worked brilliantly and never once caused an issue.

The main issue i have with the GM is that if something does crash, it does so silently and anything running after revUpdateGeometry will simply not run and it took me several days hunting this particular bug down. The only way to guess there is an issue with GM rules is to run revUpdateGeometry from the message box - if you get an error it will be completely non specific but that tells you one or more of your GM rules are funky and you shouldn't resize the stack until this is fixed...

I've logged this as a bug and asking for error messages to be generated (23521) which is confirmed by the LC team, i guess it remains to be seen if/when this is addressed...