Changed the ScaleFactor, Getting Strange Results

[Gage]

Hello!

I have recently changed the scaleFactor of a few of my stacks to 0.5, in order to produce a stack in higher resolution, so once it is deployed on mobile (iOS and Android), it can be scaled to match the screen's resolution without looking blocky. Basically, my thought is that I get to make the source file in hi-definition, so that when it is deployed, there is enough pixel data to produce a smooth looking app that rarely (if ever) needs to be scaled up.

I believe that logic is correct. End result is that I just double the heights and widths of the objects I make in the IDE, but they appear to be the same size, so I am not working with a huge looking interface on my computer screen.

However, the stack size I have chosen as standard is 660 width x 1140 height. Whenever I close a stack and reopen it, it opens with the loc of the stack shifted UP on my desktop, and the overall stack height is truncated to 967, leaving me with a 660 width x 967 height stack.

After testing on the IDE on a Mac desktop, I am getting the vertical shift, as well as the vertical stack truncation. For Windows desktop, I am only seeing the vertical shift. Meaning that the stack is not in the same location on my screen that it was when it was closed; it is higher, often with the draggable title bar behind the LiveCode navigation palette.

In and of itself, this seems like a bug. ON TOP OF THAT, I have made sure that the box marked resizable is NOT ticked, and that the liveResizing of the stack is set to false. One would think these additionally safeguard against exactly what I am experiencing.

How do I avoid this?! Where have I gone wrong? Is there a bug?

Thanks for reading! Let me know if you have any knowledge on the topic.
Phil E.

[Simon]

Hi Phil,
On Mac this is standard behavior, total height of the stack = the height of the screen - the IDE menu. But actually if you are working in .5 scale that scale should be saved when you save the stack.
Other;
Just in the preOpenStack set the height and loc of the stack, maybe that sounds like a workaround but better then having the top of the window open off screen.

Simon

[Gage]

Simon,

So... "the total height of the stack = the height of the screen - the IDE menu" ... does this mean that if I set the height of the stack in the Property Inspector to 1140 that it will for some reason be changed to a different value by default when I reopen the stack? It has never done this on any stack other than the ones I have switched to having a scaleFactor of 0.5 (Otherwise I use the default, 1).

The scaleFactor does stay saved as 0.5 when I reopen the stack, but the stack size changes such that I manually have to shift it back to 660x1140 from 660x967.

I just want to be clear about the reason that the stack is resizing from the value I set it to.

I will play with the workaround idea and see what I can muster up... sounds like this is a bug.

Thank you, friend!
Phil E.

[Simon]

Hi Phil,
Actually you should use this for hi-def;
http://lessons.runrev.com/m/15262/l/156 ... -densities
It's super fast and needs no coding.

As for the stack height getting cut on Mac, I actually never tried it on a scaled stack, full size like the full 1140 px scale 1 sure it cuts it, but I didn't think it would do the same while scaled down. (haven't tested that yet). If the 1140 on a .5 scaled stack (visually 570) still gets cropped then I would consider it a bug.
hmmm... are you setting this by code or through the inspector. I could see how through code it might come in too late.

Yeah, it's a pain that the stack gets cut, but the height and loc is a simple fix.

I guess imagine if it didn't and the height was set to 2000 px no amount of moving the stack would let you set buttons down at the bottom, if your screen height was 1024. I'm thinking before scaleFactor was introduced.

Simon

[Gage]

Simon,

Thanks for the link. Looks like the built-in stuff does most of what I need anyway.

OK, I will go ahead and report it as a bug... I think in general that stacks should be the same size and location they were when they were saved, so I will see if RunRev thinks otherwise. I am setting it through the inspector before saving, nothing is happening through code at any point to modify stack location or height as of now.

I will either switch back to smaller stacks with 1x scaleFactor or implement a workaround.

Thanks for brainstorming with me and sharing resources!
Phil E.

[jacque]

It's not a bug. LC tries to fit the stack into the current windowBoundimgRect and if it's too tall it will truncate the bottom rather than leave the drag region at the top offscreen.

The IDE sets the windowBoundimgRect to the area inside it's palettes, which gives less room than the full height of the screen. If you reset the windowBoundimgRect before opening the stack you will probably see a different result.

The scalefactor problem is interesting. It sounds like the engine is opening the stack normally within the windowBoundimgRect, which resizes it, before applying the scaling.

[Gage]

Hi jacque,

I set the scaleFactor to 1 and I think I see what you mean. The stack still has some room to play above and below it without overrunning the palettes when the stack is at the size LC resizes it to. In addition, I did set the scaleFactor to 0.5, so there is BY FAR enough room when it is displayed properly. If what you say is true, it seems as though the 0.5 scaleFactor is being applied AFTER whatever resizing protocol the engine has executes... and only on Mac. This is not an issue on PC; it only shifts the stack up vertically there without also shortening it.

I'm quite sure there IS a bug here. Even if it is just an order of operations issue when scaleFactor changes are present or the vertical shift issue that moves my stack underneath the primary top LiveCode palette. (Which I would think is another thing that the operation of resizing the stack to fit within the LC palettes would be meant to avoid).

Thanks for the feedback and support!
Phil E.