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

Brian Milby brian at milby7.com
Tue Jan 23 00:53:59 EST 2018


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 <
use-livecode at lists.runrev.com> 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 <
> 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
> >
> _______________________________________________
> 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
>



More information about the use-livecode mailing list