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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

dunbarx via use-livecode
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
round(tRSW / tOSW,2)

ratio of stack's height change is tRSHC and equals
round(tRSH / tOSH,2)




... then how (further?) wrong am I in assuming that, if I want the original
object resized and repositioned to scale on the new stack size, the NEW
RECT of that object therefore equals ...

round(item 1 of tOOR * tRSWC,0) , round(item 2 of tOOR * tRSHC,0) ,
round(item 3 of tOOR * tRSWC,0), round(item 4 of tOOR * tRSHC,0)


Sorry if that was painful. For what it's worth, I'm embarassed posting it,
but...

--
Nicolas Cueto
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

dunbarx via use-livecode
This was my first attempt also. I found that precision errors crept in. The
first resize on the mobile device worked OK but change from portrait to
landscape a few times and the precision errors become very apparent. I
rolled my own my LC resize handler that positions controls based on the
current screen rect and their relationship to other controls. LC now offers
solutions that I have not used that others have had good success with.

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]

-----Original Message-----
From: use-livecode [mailto:[hidden email]] 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 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 round(tRSW / tOSW,2)

ratio of stack's height change is tRSHC and equals round(tRSH / tOSH,2)




... then how (further?) wrong am I in assuming that, if I want the original
object resized and repositioned to scale on the new stack size, the NEW RECT
of that object therefore equals ...

round(item 1 of tOOR * tRSWC,0) , round(item 2 of tOOR * tRSHC,0) ,
round(item 3 of tOOR * tRSWC,0), round(item 4 of tOOR * tRSHC,0)


Sorry if that was painful. For what it's worth, I'm embarassed posting it,
but...

--
Nicolas Cueto
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

dunbarx via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

dunbarx via use-livecode
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 <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

dunbarx via use-livecode
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 <
[hidden email]> 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 <
> [hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

dunbarx via use-livecode
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 is done via either GM or PM.  GM controlls the changes
based on the size of the device.  PM controlls the layout for the
orientation changes.

The default profile is "Master".  Even if you do rename it, the actual
property names will still refer to themselves as "Master" in the
background.  As long as the 2 globals are set properly, creating a new
profile is as simple as changing to it.  I will agree that working with
profiles in 8/9 are going to be much more difficult than in 7 since
everything has to be done via typed commands.

My demo has 3 profiles, but going forward I would not do it that way.  If
starting a new project, I would have the main aspect ratio that I wanted to
support retain the "Master" designation and only add one additional profile
for the other.  I would experiment with renaming the master profile.

Here was my general though process when setting up the demo.

First, I decided that I wanted it to work on a small iPhone.  I set my
stack up using those dimensions.  I placed all of the controls and used the
GM to make them resize/move as needed for other device sizes.  I always
(and only) saved the stack in the smallest configuration.  I was also sure
to save before doing any testing with resizing or switching/creating
profiles.

Make sure gRevAutoCreateProfiles is true and gRevProfileReadOnly is false
(these are global variables that control profile).

Issue "revSetCardProfile profileName" command to create/switch to a new
profile (assuming the stack you are working on is the top stack).  When you
first create the new card profile, all of the objects on the card will also
get the new profile.  If you add an object later, you may need to manually
add the profile to that object (for me it actually took several switches to
get it to "take")

At this point, any changes that you make to objects will be in the new
profile.  Switching back to master should take everything back to the way
it was before and will actually save the changes into the profile that you
left (assuming gRevProfileReadOnly is false).

I would also suggest reading the dictionary entries for everything in the
"profile library" association in LC9DP11.  Even if not using that version
to develop, some of those docs were tweaked for the DP11 release.

On Mon, Jan 22, 2018 at 7:06 PM Nicolas Cueto via use-livecode <
[hidden email]> wrote:

> 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 <
> [hidden email]> 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 <
> > [hidden email]> 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
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode