LiveCode Forums.

Dear colleagues,
I designed a quite simple stack with only one card and 9 controls in it. I used the Geometry-pane in the Inspector to set the automatic resizing and position features for the controls. Resizing works fine in the LiveCode IDE but when I create a standalone Windows version the controls do not follow the resizing of the window.
In the Applications settings / General I used the standard option "Search for required inclusions when saving the standalone application".
But I also tried the other option "Select inclusions for the standalone application" and selected "Geometry" and "XML" manualy.
With no help.
I did not script any resizing code by hand therefore it cannot interfere with the automaticaly Geometry resizing of LiveCode.

Do you have any idea what could help?
Regards,
Thomas

Env: LiveCode 5.0.2 Trial, Win-7 prof. german 64 bit + SP1

Hi Thomas,

Do you have any code at all? I made a completely new, otherwise empty stack with two buttons and added some geometry settings. The standalone of this stack works fine on Win XP. Perhaps you need to do a test with a new stack.

Kind regards,

Mark

Dear Mark,

now I created a completely new stack, had the old and the new stack side by side, added again the same controls, did the same settings in the Geometry and now it works. Really, really strange.
The only thing to do is to copy over the code.

I hope this does not happen again, specialy with a more complicated UI.
I am currently in the testing mode and try different things to see if I should spend more time to LiveCode.

Thank you for your help. I works now, but I dont know why
Best regards,
Thomas

to see if I should spend more time to LiveCode.

Yes.

If you really want to get to that decision point, it will probably take about six weeks. Once you get there your world will change.

But I'd stay away from the built-in geometry management and just write your own handlers. It's not that difficult, you'll have more control over what happens, and you won't end up with surprises like this. (well, you might, but they'll be your own doing and therefore fixable).

But I'd stay away from the built-in geometry management and just write your own handlers. It's not that difficult, you'll have more control over what happens, and you won't end up with surprises like this. (well, you might, but they'll be your own doing and therefore fixable).

Sure, as a C++ MFC programmer I used to do that all the time.
But I see LiveCode in the direction as an rapid prototyping tool and would like to use it's built in automatic features. But it's disapointing to find surprises on various areas. The solution to code everything by hand is not heaven und would lead us to code in C with Win32.

For the moment it works for me. Let's see what's comming next...
Thank you,
Thomas

The strange story goes on...
After I copied my scripts over to the new created stack, the autosizing feature stops working again!!!
But I dont implement any resizing handlers. Why it stops working???
So I removed handlers one by one and checked when the autoresizing feature comes back.

Then I found the problem in the PreOpenStack handler, which just initializes some controls and global variables which seems not to be a big thing.
But one of the the global variables will be filled by an external XML file, which is like a configuration file I use all the time in different parts of the card. When I do not call "revCreateXMLTreeFromFile" in a PreOpenStack handler or use it in any other handler everything works fine.
Now I changed "PreOpenStack" into "PreOpenCard" and this helps to let the autosizing work.
I checked now the documentation in the Dictionary but it does not mention one should avoid any "unsafe" commands in PreOpenStack.
Regards,
Thomas

Thomas- well, there aren't "unsafe" commands as such for a preOpenStack handler, but it's still possible to get into trouble. The thing to remember is that preOpenStack is executed *before* anything has been instantiated onto the screen. So if you try to affect the visual placement of objects before they're even shown your code won't have any effect. For that, as you've discovered, you'll have much better results doing that in preOpenCard or openStack or openCard.

So if you try to affect the visual placement of objects before they're even shown your code won't have any effect

But I don't write any code which affects the visual placement of anything.
The only thing I did was to read from an external file using "revCreateXMLTreeFromFile". Nothing else.
I think - as you described - there are any uninitialized internals and LC depends on a specific initialization order of them. E.g. let LC create it's visual subsystem before calling other (maybe external) components.
Therefore I learned the "rule": Don't call any XML routine before the visual components were built at least in memory.

Would be nice there is a documentation about this.
But I gave up hope. At the time we use LC 5.0.2 the user guide is more than a year old V4.x, incomplete (it even doesn't describe any repeat loop commands) and incorrect (figure numbers, references to other positions,... Did anybody seriously read this document???).
Regards,
Thomas