jacque wrote: ↑Tue Feb 27, 2018 8:59 pm
FullscreenMode isn't just rarely needed unless you're Richard.
I didn't write "rarely desirable", just "rarely
needed". If you like what it does, use it.
When I study apps like GMail, YouTube, Evernote, Google Maps, Apple Maps, LinkedIn, Facebook, Twitter, and others, I see that they use dynamic positioning. What those UIs need across all possible screen sizes and orientations is more than scaling one fixed layout can provide.
And on the flipside, when I see Monument Valley I see one of the most beautiful apps ever made, and one for which fullScreenMode is an excellent fit.
There is no single option that is the best for all possible apps. I believe it's helpful to study apps of the sort one aspires to make, and use the options provided for those kinds of apps. Thankfully the documentation for fullScreenMode is as good as for the resizeStack message and related positioning properties, so we can choose among them to do whatever we need for the task at hand.
In this case, the OP's layout has a header and footer of fixed height, with a body region that needs to be adjust dynamically to maintain the header and footer size while filling the space in between.
I would absolutely love a single property setting that could review UI details like that and automatically handle control repositioning for me. But until we get that, we're no worse off than the rest of the world who also nees to handle dynamic positioning in many types of apps like the OPs, using responsive design practices.
I use it in every mobile app I've made since it was introduced.
I've installed a couple of your apps, and I like 'em. Where it works for the types of apps one's making, definitely use it. It's a time saver.
But if your UI could benefit from more precise positioning, fear not. Nearly every desktop app made over the last 20 years has relied on resizeStack handlers to position controls, so it's not like we need to learn much that's new or untested. Besides, LiveCode is a scripting tool; we expect to do some scripting now and then. The most complex layouts I've ever scripted were merely tedious, but not difficult. Most take just a few minutes. These days we have better messaging with groups that can keep layout logic centralized to regions of a card, making the scripting even easier.
And when the specifics of an app's needs allow for the unusual ease of getting exactly what you want with a single property setting, by all means use it.
It does not cause the problem described.
Except on the desktop on non-Mac systems, where he was seeing the problem. What he described with his Windows experience is not entirely consistent with what I've seen here on Windows and Linux, but close enough to a couple bug reports I've submitted that it seemed worth at least temporarily running without fullscreenmode as a quick test.
The "freeze" is more likely due to a problem in the debugger.
If he's running the app while stepping through the debugger, that's a detail I'd overlooked. Yes, stepping through code with the debugger will slow things down tremendously over just letting code run unimpeded. Most definitely repeat the test without the debugger to narrow down possible cause.