That stack was a demo/proof of concept that GM and PM could work on
Mobile. Before LC9DP11, those script libraries were not available by
default when creating an app for iOS/Android. The demo stack actually
includes the library code to make them work. All of the movements/changes
to the controls
Brian Milby wrote:
The GM avoids the cumulative error problem by storing positioning as fixed
numbers in the GM custom properties. It will either store absolute pixel
positions or relative % of card dimension positions. Positions are based
on either a card edge or another control edge. So for y
To demonstrate, the following formula:
5 * 3 * .5 * .66 = 4.95 (not 5)
hence the need to store a base size and always work your math from that.
Bob S
> On Jan 19, 2018, at 07:53 , Brian Milby via use-livecode
> wrote:
>
> The calculations that you are making are sound, but as Ralph said, a
The calculations that you are making are sound, but as Ralph said, after
repeated changes it may end up "off".
The type of positioning that you are doing is one of the things that the
current Geometry Manager (GM) Property Inspector (PI) will not allow (when
you resize a control, the left/top can
...@lists.runrev.com] On Behalf
Of Nicolas Cueto via use-livecode
Sent: Friday, January 19, 2018 1:34 AM
To: How to use LiveCode
Cc: Nicolas Cueto
Subject: resizing and rescaling an object: Is this math/logic ok?
Given these values...
original STACK-width is tOSW
original stack-height is tOSH
resized
Given these values...
original STACK-width is tOSW
original stack-height is tOSH
resized stack-width is tRSW
resized stack-height of stack is tRSH
original OBJECT rect is tOOR (i.e., left,top,right,bottom)
... and assuming I'm right that ...
ratio of stack's width change is tRSWC and equals
