Mobile Rotation Redux

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

Mobile Rotation Redux

Stephen MacLean via use-livecode
I finally installed Android Studio.  I have API 28, 26, and 15 installed.
Everything else was pretty much the defaults.  (Hint: you don't need to
move the sdk directory out of your Library, just create an alias and put it
on your desktop.  When you select the alias, LC will resolve it and store
the actual path.)

I couldn't get the (slow) emulators to launch.  Finding AVD in Studio is
somewhat of a pain (had to create a project to get the menu option).  Log
had some complaint about a file not being in the right place.

I decided to try to build a simple app and put it on my 5th Gen Fire (Fire
OS 5.6.1.0).  Ended up putting the apk on Dropbox, then copying it to the
SD card on the Fire, then installing the app (for some reason trying to
install directly from Dropbox didn't want to work).

Stack has 3 objects on the only card:  field "label", field "log", and
widget "Browser"
Objects all resize and move based on the rect (log and browser positions
change when rotated to landscape).  In LC, the stack is saved as 320x480 to
be sure that it has to resize.

I'll post the stack file if anyone wants to see it.  On the one Android
device I have available it works correctly.  Resizestack handlers fire
correctly.  So I guess I need to find something with a later OS to test
against to see the problems others are seeing on the Android side.

I linked the label field to open the r9 demo stack from the other thread
and it worked fine as well.

Here is the stack script:
---------------------------------------------------
on preOpenStack
   logRects "stack preOpenStack"
   pass preOpenStack
end preOpenStack

command logRects pText
   put pText & lf & \
         "   stack rect" && the rect of this stack & lf & \
         "   screenrect" && the screenrect & lf \
         after field "log" of card id 1002 of me
end logRects


Here is the card script:
---------------------------------------------------
on preOpenStack
   if the environment is "mobile" then
      local tOrientations
      put "portrait,portrait upside down,landscape left,landscape right"
into tOrientations
      mobileSetAllowedOrientations tOrientations
   end if
   --
   logRects "card preOpenStack"
   pass preOpenStack
end preOpenStack

on preOpenCard
   logRects "card preOpenCard"
end preOpenCard

on openCard
   logRects "card openCard"
end openCard

on resizeStack pNewWidth, pNewHeight, pOldWidth, pOldHeight
   logRects "resizeStack" && pNewWidth & slash & pNewHeight & \
         slash & pOldWidth & slash & pOldHeight

   local tMid
   if pNewWidth > pNewHeight then
      -- landscape
      put round(pNewWidth/2) into tMid
      set the rect of field "log" of me to 24,48,tMid-12,pNewHeight-24
      set the rect of widget "Browser" of me to
tMid+12,48,pNewWidth-24,pNewHeight-24
   else
      -- portrait
      put round(pNewHeight/2) into tMid
      set the rect of field "log" of me to 24,48,pNewWidth-24,tMid-12
      set the rect of widget "Browser" of me to
24,tMid+12,pNewWidth-24,pNewHeight-24
   end if
   set the rect of field "label" of me to 24,12,pNewWidth-24,48
end resizeStack


This is probably a good basic stack that could be used to gather
information on when events are firing and when values are getting updated.
For example, a send in time could be used to check the rects a certain
amount of time after the openCard finished.
_______________________________________________
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: Mobile Rotation Redux

Stephen MacLean via use-livecode
On 8/30/18 8:46 PM, Brian Milby via use-livecode wrote:
> I'll post the stack file if anyone wants to see it.  On the one Android
> device I have available it works correctly.  Resizestack handlers fire
> correctly.  So I guess I need to find something with a later OS to test
> against to see the problems others are seeing on the Android side.

Sure, post the stack and I'll take a look on a couple of different
Android devices.

For the record, I haven't had any problems on Android with resizeStack
or the various rects either. I don't remember exactly, but I seem to
recall the reported problems were with a stack that uses fullscreenMode,
where resizeStack isn't sent (unless
mobileSetFullScreenRectForOrientations is used.)

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
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: Mobile Rotation Redux

Stephen MacLean via use-livecode
As I like to do, I decided to really over-do the demo test stacks.  The one
I mentioned initially is:

https://milby.us/lc/RotationDemo.livecode

The one I just finished working on does a bit more:

https://milby.us/lc/MobileDemo.livecode

I built both to test resizeStack and rotation on Android.  I only have a 5"
Fire, so I only was able to test on one device.  The first stack is just a
log field and a browser widget.  Nothing special, but it does log the rect
every time a resize happens (rotation).  When the app opens, you will
notice the rect of the stack is the one from the desktop version.  It is
saved at 320x480 on purpose to ensure that just about every device will
need to resize it.

The second stack also is built at 320x480.  That one does a couple of
things.  Depending on the screen width, the buttons are either in a single
row or two rows for each group.  The first group sets the FullScreenMode
(FSM) of the stack.  The stack will store the last mode set and restore
that mode when relaunching (I got that idea from the other thread).  The
second group will set the size of the stack.  Those buttons only have an
effect if one of the FSMs is in use (i.e. not "empty"). The currently
active mode and size are outlined in red.

The stack rect is outlined in red with a Cantaloupe background fill.  The
screen rect is outlined in green with a Mocha fill (only visible in
"showAll" mode).  On my device, I used a 200ms delay to adjust the screen
rect graphic when changing orientation.  I could probably take it down a
little bit more.  If your device is slower on the rotate and that rect does
not adjust, you can lay the device flat (face up) and it should notice the
change and fix it.  I did not attempt to use any of the new messages for
FSM rotation so everything gets really small when you rotate while using a
FSM.  (In my mind the two really don't go together -

The stack initially will launch with FSM empty which means that it will
fill the screen.  The rect does get set to the effective working screenrect
automatically, but I noticed some strangeness when moving to another mode.
To address that issue on my device, I manually changed the stack rect to
320x480 and then back to the effective working screenrect.  That seems to
allow changing to other modes without difficulty.

What is it good for?  Two things.  First is to test messages on various
devices.  Specifically to see when the new rect is available and what the
device thinks various rects are.  Second is an interactive test of how FSM
will adjust a stack on a device.  When you select a mode, it will resize
the stack to the native resolution of the device.  The size buttons can
then be used to set the size that you would be developing the stack in.
I've used the default iPhone/iPad sizes to provide a sample, but they can
be changed without too much difficulty (names would need to be changed in
the code, but the 5 size button labels can be changed independently without
needing to update the code).

In the other thread (actually the start of it), there was a question about
how to get a background object to fill the screen in FSM.  The mocha/green
object is the one that does that here.  To see the effect, use the
"showAll" mode and select the iPad size.  On the 5" Fire, everything is
really small at that size.  It becomes quite obvious when you rotate since
much of the screen space is "extra".

Hope it is helpful for someone.  I had fun making it as my first stab at
Android work.

Brian

On Fri, Aug 31, 2018 at 1:26 PM J. Landman Gay via use-livecode <
[hidden email]> wrote:

> On 8/30/18 8:46 PM, Brian Milby via use-livecode wrote:
> > I'll post the stack file if anyone wants to see it.  On the one Android
> > device I have available it works correctly.  Resizestack handlers fire
> > correctly.  So I guess I need to find something with a later OS to test
> > against to see the problems others are seeing on the Android side.
>
> Sure, post the stack and I'll take a look on a couple of different
> Android devices.
>
> For the record, I haven't had any problems on Android with resizeStack
> or the various rects either. I don't remember exactly, but I seem to
> recall the reported problems were with a stack that uses fullscreenMode,
> where resizeStack isn't sent (unless
> mobileSetFullScreenRectForOrientations is used.)
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> 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: Mobile Rotation Redux

Stephen MacLean via use-livecode
I ran both stacks on my Pixel and they got exactly the same results you
reported; in other words, everything worked just fine.

I decided to try my theory that we could combine fullscreenMode with
individual object placement and we can. This will prevent the tiny image
when the device is rotated to landscape. Basically, for a stack that is
taller than it is wide, you want showAll in portrait and noBorder in
landscape. All I had to do was revise your orientationChanged handler
and add some logic to determine the correct fullscreenMode. I suspect
mobileSetFullScreenRectForOrientations would do the same thing, but I
wasn't focused on that.

So in the MobileDemo stack, revise orientationChanged and add the FSM
function and it should work. The rest of the handlers can remain as-is.
This particular revision only assumes we're using showAll and noBorder;
it doesn't address any others. Those are the two that almost all mobile
apps use.

on orientationChanged
   if the fullscreenmode of this stack is not empty then
     send "setBackground" to me in 200 milliseconds
     send "setFSM" to me in 250 milliseconds
     -- updateStatus "Orientation:" && mobileDeviceOrientation()
   end if
end orientationChanged

on setFSM
   if the fullscreenmode of this stack is not among the items of
"showAll,noBorder" then exit setFSM
   set the rect of this stack to the effective working screenRect
   if mobileDeviceOrientation() contains "landscape" then
     set the fullscreenmode of this stack to "noBorder"
   else if mobileDeviceOrientation() contains "portrait" then
     set the fullscreenmode of this stack to "showAll"
   end if
   updateStatus "setFSM:" && the fullscreenmode of this stack
   set the backcolor of this cd to the backcolor of this cd
end setFSM

I had to use your "set the rect of this stack" method to force
fullscreenMode to resolve, that's a nice trick. Setting the backcolor of
the card to its existing color is a hack workaround that Panos
discovered which forces a card redraw. That eliminates the issue where
objects outside the card rect don't redraw properly, so now you don't
need to lay the device flat to do it.

I did wonder why you need the math in the setBackground handler. Doesn't
the working screenrect give the right measurements?


On 9/1/18 1:35 AM, Brian Milby via use-livecode wrote:

> As I like to do, I decided to really over-do the demo test stacks.  The one
> I mentioned initially is:
>
> https://milby.us/lc/RotationDemo.livecode
>
> The one I just finished working on does a bit more:
>
> https://milby.us/lc/MobileDemo.livecode
>
> I built both to test resizeStack and rotation on Android.  I only have a 5"
> Fire, so I only was able to test on one device.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
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: Mobile Rotation Redux

Stephen MacLean via use-livecode
Thanks for running the tests!

I've been working on this stack for the past 2 days.  I've made quite a bit
of progress and switched to using the new handler to set orientation
rects.  That simplifies things a bit.  I had to write some code to figure
out the rect to use for device native though (which wouldn't be an issue
for a real app since your rect would be fixed at design time).

The math is required because you need to translate the rect.  The
screenrect is absolute for the device.  The graphic rect is relative to the
card.  This is only needed for the "showAll" fullscreenmode.

I'm planning on turning the button position action into a group behavior.
Once I get that done, I'll post an update.

Thanks,
Brian

On Mon, Sep 3, 2018 at 4:24 PM J. Landman Gay via use-livecode <
[hidden email]> wrote:

> I ran both stacks on my Pixel and they got exactly the same results you
> reported; in other words, everything worked just fine.
>
> I decided to try my theory that we could combine fullscreenMode with
> individual object placement and we can. This will prevent the tiny image
> when the device is rotated to landscape. Basically, for a stack that is
> taller than it is wide, you want showAll in portrait and noBorder in
> landscape. All I had to do was revise your orientationChanged handler
> and add some logic to determine the correct fullscreenMode. I suspect
> mobileSetFullScreenRectForOrientations would do the same thing, but I
> wasn't focused on that.
>
> So in the MobileDemo stack, revise orientationChanged and add the FSM
> function and it should work. The rest of the handlers can remain as-is.
> This particular revision only assumes we're using showAll and noBorder;
> it doesn't address any others. Those are the two that almost all mobile
> apps use.
>
> on orientationChanged
>    if the fullscreenmode of this stack is not empty then
>      send "setBackground" to me in 200 milliseconds
>      send "setFSM" to me in 250 milliseconds
>      -- updateStatus "Orientation:" && mobileDeviceOrientation()
>    end if
> end orientationChanged
>
> on setFSM
>    if the fullscreenmode of this stack is not among the items of
> "showAll,noBorder" then exit setFSM
>    set the rect of this stack to the effective working screenRect
>    if mobileDeviceOrientation() contains "landscape" then
>      set the fullscreenmode of this stack to "noBorder"
>    else if mobileDeviceOrientation() contains "portrait" then
>      set the fullscreenmode of this stack to "showAll"
>    end if
>    updateStatus "setFSM:" && the fullscreenmode of this stack
>    set the backcolor of this cd to the backcolor of this cd
> end setFSM
>
> I had to use your "set the rect of this stack" method to force
> fullscreenMode to resolve, that's a nice trick. Setting the backcolor of
> the card to its existing color is a hack workaround that Panos
> discovered which forces a card redraw. That eliminates the issue where
> objects outside the card rect don't redraw properly, so now you don't
> need to lay the device flat to do it.
>
> I did wonder why you need the math in the setBackground handler. Doesn't
> the working screenrect give the right measurements?
>
>
> On 9/1/18 1:35 AM, Brian Milby via use-livecode wrote:
> > As I like to do, I decided to really over-do the demo test stacks.  The
> one
> > I mentioned initially is:
> >
> > https://milby.us/lc/RotationDemo.livecode
> >
> > The one I just finished working on does a bit more:
> >
> > https://milby.us/lc/MobileDemo.livecode
> >
> > I built both to test resizeStack and rotation on Android.  I only have a
> 5"
> > Fire, so I only was able to test on one device.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> 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: Mobile Rotation Redux

Stephen MacLean via use-livecode
I've posted an updated version of the stack:
https://milby.us/lc/MobileDemo2.livecode

This version uses the new properties for orientation rects which causes the
engine to send resizestack messages on rotation.  I've also moved the
buttons into a background groups with a behavior that handles the layout
adjustment.  The card resize handler sets the width of the group and then
the group takes care of moving the buttons and adjusting the height (thanks
to Richard's hint in another thread).  Then the card sets the top and width
of the second group which does the same process for the buttons within.
Then the field object is sized based on those changes.

Except for "deviceMax", the button names for the size buttons can be
changed.  The label is what is used for the actual size, so if someone
wanted to test different stack rects they just need to make changes to the
labels.  If the device is in "landscape", then the numbers are swapped when
setting the rect.

The main part of the card is taken up by a field that contains a log of
messages that are received by the app.  It is fairly verbose and whenever
the stack is resized it includes the rects.

One interesting thing I found (possibly a bug) is that (pre)openBackground
messages seem to have an issue if there are multiple backgrounds (multiple
messages sent to a single background instead of one message to each
background).  This issue seems to go back as least as far as LC 6.7.11
(didn't test earlier) on my Mac.  It doesn't matter if the script is in a
behavior or not (tested separately).  If someone can confirm that this
should be reported as a bug, I'll take care of it.

Next thing to add is some navigation and additional cards.  One thought
that I had was a grid (100px major, 25px minor) and some objects to see how
the changes impact the way things look (particularly circles).

Thanks,
Brian

On Mon, Sep 3, 2018 at 4:59 PM Brian Milby <[hidden email]> wrote:

> Thanks for running the tests!
>
> I've been working on this stack for the past 2 days.  I've made quite a
> bit of progress and switched to using the new handler to set orientation
> rects.  That simplifies things a bit.  I had to write some code to figure
> out the rect to use for device native though (which wouldn't be an issue
> for a real app since your rect would be fixed at design time).
>
> The math is required because you need to translate the rect.  The
> screenrect is absolute for the device.  The graphic rect is relative to the
> card.  This is only needed for the "showAll" fullscreenmode.
>
> I'm planning on turning the button position action into a group behavior.
> Once I get that done, I'll post an update.
>
> Thanks,
> Brian
>
> On Mon, Sep 3, 2018 at 4:24 PM J. Landman Gay via use-livecode <
> [hidden email]> wrote:
>
>> I ran both stacks on my Pixel and they got exactly the same results you
>> reported; in other words, everything worked just fine.
>>
>> I decided to try my theory that we could combine fullscreenMode with
>> individual object placement and we can. This will prevent the tiny image
>> when the device is rotated to landscape. Basically, for a stack that is
>> taller than it is wide, you want showAll in portrait and noBorder in
>> landscape. All I had to do was revise your orientationChanged handler
>> and add some logic to determine the correct fullscreenMode. I suspect
>> mobileSetFullScreenRectForOrientations would do the same thing, but I
>> wasn't focused on that.
>>
>> So in the MobileDemo stack, revise orientationChanged and add the FSM
>> function and it should work. The rest of the handlers can remain as-is.
>> This particular revision only assumes we're using showAll and noBorder;
>> it doesn't address any others. Those are the two that almost all mobile
>> apps use.
>>
>> on orientationChanged
>>    if the fullscreenmode of this stack is not empty then
>>      send "setBackground" to me in 200 milliseconds
>>      send "setFSM" to me in 250 milliseconds
>>      -- updateStatus "Orientation:" && mobileDeviceOrientation()
>>    end if
>> end orientationChanged
>>
>> on setFSM
>>    if the fullscreenmode of this stack is not among the items of
>> "showAll,noBorder" then exit setFSM
>>    set the rect of this stack to the effective working screenRect
>>    if mobileDeviceOrientation() contains "landscape" then
>>      set the fullscreenmode of this stack to "noBorder"
>>    else if mobileDeviceOrientation() contains "portrait" then
>>      set the fullscreenmode of this stack to "showAll"
>>    end if
>>    updateStatus "setFSM:" && the fullscreenmode of this stack
>>    set the backcolor of this cd to the backcolor of this cd
>> end setFSM
>>
>> I had to use your "set the rect of this stack" method to force
>> fullscreenMode to resolve, that's a nice trick. Setting the backcolor of
>> the card to its existing color is a hack workaround that Panos
>> discovered which forces a card redraw. That eliminates the issue where
>> objects outside the card rect don't redraw properly, so now you don't
>> need to lay the device flat to do it.
>>
>> I did wonder why you need the math in the setBackground handler. Doesn't
>> the working screenrect give the right measurements?
>>
>>
>> On 9/1/18 1:35 AM, Brian Milby via use-livecode wrote:
>> > As I like to do, I decided to really over-do the demo test stacks.  The
>> one
>> > I mentioned initially is:
>> >
>> > https://milby.us/lc/RotationDemo.livecode
>> >
>> > The one I just finished working on does a bit more:
>> >
>> > https://milby.us/lc/MobileDemo.livecode
>> >
>> > I built both to test resizeStack and rotation on Android.  I only have
>> a 5"
>> > Fire, so I only was able to test on one device.
>>
>> --
>> Jacqueline Landman Gay         |     [hidden email]
>> HyperActive Software           |     http://www.hyperactivesw.com
>>
>> _______________________________________________
>> 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: Mobile Rotation Redux

Stephen MacLean via use-livecode
With an astute observation from Jaque, I was able to figure out why the
messages didn't seem to be flowing properly.  Since I only read the
openBackground entry, I missed the note about needing to pass the message
for other backgrounds to handle.  I've updated the file that I posted.
Eventually I will put it on GitHub with a proper license file, but the code
is going to be GPL compatible for use in the Community Edition.

https://milby.us/lc/MobileDemo2.livecode

Would something like this be useful as a test for device/OS combinations?
I could add a button to email the log and a standard protocol could be
developed and the output validated.

Thanks,
Brian

On Wed, Sep 5, 2018 at 10:20 AM Brian Milby <[hidden email]> wrote:

> I've posted an updated version of the stack:
> https://milby.us/lc/MobileDemo2.livecode
>
> This version uses the new properties for orientation rects which causes
> the engine to send resizestack messages on rotation.  I've also moved the
> buttons into a background groups with a behavior that handles the layout
> adjustment.  The card resize handler sets the width of the group and then
> the group takes care of moving the buttons and adjusting the height (thanks
> to Richard's hint in another thread).  Then the card sets the top and width
> of the second group which does the same process for the buttons within.
> Then the field object is sized based on those changes.
>
> Except for "deviceMax", the button names for the size buttons can be
> changed.  The label is what is used for the actual size, so if someone
> wanted to test different stack rects they just need to make changes to the
> labels.  If the device is in "landscape", then the numbers are swapped when
> setting the rect.
>
> The main part of the card is taken up by a field that contains a log of
> messages that are received by the app.  It is fairly verbose and whenever
> the stack is resized it includes the rects.
>
> One interesting thing I found (possibly a bug) is that (pre)openBackground
> messages seem to have an issue if there are multiple backgrounds (multiple
> messages sent to a single background instead of one message to each
> background).  This issue seems to go back as least as far as LC 6.7.11
> (didn't test earlier) on my Mac.  It doesn't matter if the script is in a
> behavior or not (tested separately).  If someone can confirm that this
> should be reported as a bug, I'll take care of it.
>
> Next thing to add is some navigation and additional cards.  One thought
> that I had was a grid (100px major, 25px minor) and some objects to see how
> the changes impact the way things look (particularly circles).
>
> Thanks,
> Brian
>
> On Mon, Sep 3, 2018 at 4:59 PM Brian Milby <[hidden email]> wrote:
>
>> Thanks for running the tests!
>>
>> I've been working on this stack for the past 2 days.  I've made quite a
>> bit of progress and switched to using the new handler to set orientation
>> rects.  That simplifies things a bit.  I had to write some code to figure
>> out the rect to use for device native though (which wouldn't be an issue
>> for a real app since your rect would be fixed at design time).
>>
>> The math is required because you need to translate the rect.  The
>> screenrect is absolute for the device.  The graphic rect is relative to the
>> card.  This is only needed for the "showAll" fullscreenmode.
>>
>> I'm planning on turning the button position action into a group
>> behavior.  Once I get that done, I'll post an update.
>>
>> Thanks,
>> Brian
>>
>> On Mon, Sep 3, 2018 at 4:24 PM J. Landman Gay via use-livecode <
>> [hidden email]> wrote:
>>
>>> I ran both stacks on my Pixel and they got exactly the same results you
>>> reported; in other words, everything worked just fine.
>>>
>>> I decided to try my theory that we could combine fullscreenMode with
>>> individual object placement and we can. This will prevent the tiny image
>>> when the device is rotated to landscape. Basically, for a stack that is
>>> taller than it is wide, you want showAll in portrait and noBorder in
>>> landscape. All I had to do was revise your orientationChanged handler
>>> and add some logic to determine the correct fullscreenMode. I suspect
>>> mobileSetFullScreenRectForOrientations would do the same thing, but I
>>> wasn't focused on that.
>>>
>>> So in the MobileDemo stack, revise orientationChanged and add the FSM
>>> function and it should work. The rest of the handlers can remain as-is.
>>> This particular revision only assumes we're using showAll and noBorder;
>>> it doesn't address any others. Those are the two that almost all mobile
>>> apps use.
>>>
>>> on orientationChanged
>>>    if the fullscreenmode of this stack is not empty then
>>>      send "setBackground" to me in 200 milliseconds
>>>      send "setFSM" to me in 250 milliseconds
>>>      -- updateStatus "Orientation:" && mobileDeviceOrientation()
>>>    end if
>>> end orientationChanged
>>>
>>> on setFSM
>>>    if the fullscreenmode of this stack is not among the items of
>>> "showAll,noBorder" then exit setFSM
>>>    set the rect of this stack to the effective working screenRect
>>>    if mobileDeviceOrientation() contains "landscape" then
>>>      set the fullscreenmode of this stack to "noBorder"
>>>    else if mobileDeviceOrientation() contains "portrait" then
>>>      set the fullscreenmode of this stack to "showAll"
>>>    end if
>>>    updateStatus "setFSM:" && the fullscreenmode of this stack
>>>    set the backcolor of this cd to the backcolor of this cd
>>> end setFSM
>>>
>>> I had to use your "set the rect of this stack" method to force
>>> fullscreenMode to resolve, that's a nice trick. Setting the backcolor of
>>> the card to its existing color is a hack workaround that Panos
>>> discovered which forces a card redraw. That eliminates the issue where
>>> objects outside the card rect don't redraw properly, so now you don't
>>> need to lay the device flat to do it.
>>>
>>> I did wonder why you need the math in the setBackground handler. Doesn't
>>> the working screenrect give the right measurements?
>>>
>>>
>>> On 9/1/18 1:35 AM, Brian Milby via use-livecode wrote:
>>> > As I like to do, I decided to really over-do the demo test stacks.
>>> The one
>>> > I mentioned initially is:
>>> >
>>> > https://milby.us/lc/RotationDemo.livecode
>>> >
>>> > The one I just finished working on does a bit more:
>>> >
>>> > https://milby.us/lc/MobileDemo.livecode
>>> >
>>> > I built both to test resizeStack and rotation on Android.  I only have
>>> a 5"
>>> > Fire, so I only was able to test on one device.
>>>
>>> --
>>> Jacqueline Landman Gay         |     [hidden email]
>>> HyperActive Software           |     http://www.hyperactivesw.com
>>>
>>> _______________________________________________
>>> 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