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 <br...@milby7.com> 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 <br...@milby7.com> 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 < >> use-livecode@lists.runrev.com> 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 | jac...@hyperactivesw.com >>> HyperActive Software | http://www.hyperactivesw.com >>> >>> _______________________________________________ >>> use-livecode mailing list >>> use-livecode@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
