Browser Widget Fails to Re position

Sannyasin Brahmanathaswami brahma at hindu.org
Sun Jun 26 18:01:11 EDT 2016


I am struggling with a bug that was reported in February, and confirmed by  the team, but remains unsolved. it's been so long that I posted a new bug report here, not remembering that I had one already in that related but is five months old

http://quality.livecode.com/show_bug.cgi?id=17906

And the confirmed one is here:

http://quality.livecode.com/show_bug.cgi?id=16965


It's a blocker for me, so I looking for "hack-arounds" --perhaps we need to even go so far as to change our methods/architecture, where we intend, hopefully to make heavy use of the browser widget so that we can flip between native LC content, web content and HTML5 content on the fly.

If you are interested you can download my "prototype" stack here:

http://wiki.hindu.org/screenshots/surprise-me.zip

this stack will eventually pull media from the web server.

Challenge: the use case is to have cards render initially on mobile in portrait orientation, but when moving to card 3 the stack size is dynamically changed to 736w X 414h i.e. switches from portrait to landscape in order to accommodate a full screen browser widget rect 0,0,414,746. then moving back to another card, switches to portrait.

Since the app intends to include a lot of content that needs to be view in a locked Portrait OR locked Landscape orientation, the goal was to find methods that would all for doing this dynamically as we move from one card to the next, all in the same stack. To make matters more dicy, we are using set fullscreenmode to "show all"

My algorithm was:

- set a custom prop on each card "uOrientation"  which is hard wired to either "Portrait" or "Landscape"
- preopen card handler the reformats the rect and layout

on preopencard
   setOrientation
end preopencard


on setOrientation

   put the uOrientation of this card into tCurrentCardOrientation

   if tCurrentCardOrientation is "Landscape" then

      if isMobile() then mobileSetAllowedOrientations  "landscape right, landscape left"

      set the width of this stack to 736

      set the height of this stack to 414

      setBarLocations

      setBottomNavtoSideAndBack "Side"

   else

      if isMobile() then mobileSetAllowedOrientations  "portrait, portrait upside down"

      set the width of this stack to 414

      set the height of this stack to 736

      setBarLocations

      setBottomNavtoSideAndBack bottom"

   end if

   --set the loc of this stack to the screenloc

end setOrientation



Whether this is the smartest approach or not… I don't know… I'm a newbie at this orientation change business. But it works pretty well… almost… the Browser widget will not respond to a command to reposition.



on card three we have:



on preopencard

   setOrientation

   set the topleft of widget "surpriseBrowser" to 0,0

   put 0 into gBrowserStatusFlag

   hide grp "homeScreensBottomNav"

end preopencard



On desktop, to get around the bug I have to do this "hacky thingy" on that same card:



on opencard

choose pointer tool

choose browser tool # the browser widget jumps to the assigned rect 0,0,141,736

send checkBrowserState to me in 3 seconds

end opencard



On mobile, after introducing these commands



if isMobile() then mobileSetAllowedOrientations "landscape right, landscape left"

if isMobile() then mobileSetAllowedOrientations "portrait, portrait upside down"

all the "native" LC controls behave perfectly in iOS, but the browser widget fails to appear on my iPhone



Any ideas? Anyone else doing portrait/landscape/portrait switching "on the fly" with a browser widget?



FYI side note I was able to get the card to respond to a mousedown when the browser widget covered the whole card and so control/move the position of the browser widget to expose stack navigation when in full screen mode. So if you get to card three and things look strange, just mousedown and hold an navigation will appear, then hide it with the icon the bottom left.

I'm off now to see if I break out that browser widget to a substack with a fixed size… if that helps.



BR

























More information about the use-livecode mailing list