resizing and rescaling an object: Is this math/logic ok?

[Nicolas Cueto]

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 your situation, you
would want to calculate the offset % for each side and then just use the
new card dimensions to calculate the new control rect.

Took days to figures out and test but that worked! Thank you, Brian.

Thank you Brian too for your stack "MobileProfile", which I found on a
forum thread
<http://forums.livecode.com/viewtopic.php?f=7&t=30018&p=159472&hilit=full+screen+mobile#p159472>
when
searching for anything having to do with rescaling/resizing. That stack
(which is way over my head), besides a source of ideas for resizing, was
also my first introduction to "profiles".

BTW and OTT, Brian, about your use of "profiles" in that stack, I was
especially and idiotically mesmerized by how those three graphic objects
become not only repositioned but colored in when in landscape profile, as
oposed to transparent when in portrait profile. Not knowing diddly-squat
about "profiles", I thought I might use LC's "Find & replace" to find
somehow a refence (by object name or background color) to those three
graphic objects, and thereby hit upon the contents of your stack's
"profiles". But, like I say, diddly-squat. Perhaps a few pointers about
"profiles", especially how they're used in "MobileProfile", when you have a
few spare moments? Sorry to ask directly, but, as I say, how your stack
works seems magical to these eyes.

Anyway, thank you all for the help. Now, onto the other recaling problems,
such as text size.

--
Nicolas Cueto

On 20 January 2018 at 01:26, Bob Sneidar via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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 <
> use-livecode at lists.runrev.com> wrote:
> >
> > 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 only be fixed to the card edge and
> > not proportional).  But, the method that the GM uses is helpful to know.
> >
> > 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 your situation,
> you
> > would want to calculate the offset % for each side and then just use the
> > new card dimensions to calculate the new control rect.
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>