LiveCode Forums.

I was making an application for mobile devices and wrote some custom resizing functions and commands loosely based on TickedOff-stage9.
When I tested it in the android sdk emulator, it didn't look so good.
So I tried the TickedOff-stage9.livecode file to see how that coped on the emulator; It didn't look good either. I was just wondering if this is kinda normal? Some teething problems? Has anyone else experienced this kind of issue?
TickedOff-stage9 works fine when resizing on desktop.

No, not normal. The original worked, so I wonder if the resizeStack handler was changed?

The original Stage9 works on my 5554:Android-2p2-API-8.

hth

I worked it out!
But maybe you can explain to me why it works:
I had to "Lock size and position" for all the images.
I remember something mentioned about that in the 2011 runrev developers conference when they were doing the tutorial and the speaker was demonstrating how to resize and import images.
Why is it that images automatically resize to their original size when you revisit the card unless you specifically lock the size and position?

It takes a lot of people by surprise, but that's how it works. Groups behave the same way. Unlocked images revert to their native dimensions and groups revert to encompass their contents if they aren't locked. If locked, both retain their set sizes.

For images, it allows you to scale an image temporarily and not worry about setting it back to its normal size when you return to the card because that will happen automatically. Another common use for the behavior is to re-use an image object repeatedly to show different photos, for example. When you put a new photo into the image object, it automatically resizes to accomodate the entire image (which is a very easy way to find out an image's dimensions too.) For groups, moving or resizing any of the contents allows the group to adapt immediately to the size of its contents which may or may not be what you need. In either case, locking the image or the group prevents resizing.

There have been discussions about which way the default should be, but it's a toss-up. Different applications require different behaviors and it usually works out that about 50% of developers want it changed.

Why not have an option where the developer can set the default to his preference?

thanks jacque