Any idea why when trying in LiveCode that the browser widget is near the bottom of the card window?
As an aside, are there any licensing issues involve in getting permission to embed a YouTube video in an app’s web view? Also, you should continue the tab bar off the left and right of the card window, out to 552 wide, and continue any background patterns out that far too, so that it gets revealed on iPhone 4 and iPad. As it stands it would switch to a flat color at the edges, which may be acceptable, but could look better. > On Jun 26, 2016, at 6:01 PM, Sannyasin Brahmanathaswami <[email protected]> > wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
