Browser Widget Fails to Re position

Colin Holgate colinholgate at gmail.com
Sun Jun 26 22:52:39 EDT 2016


I don’t know if you tried it, but if you show the position of the browser when you get to the card, it’s already 0,0. Until that symptom is fixed it may confuse the other symptoms.


> On Jun 26, 2016, at 10:10 PM, Sannyasin Brahmanathaswami <brahma at hindu.org> wrote:
> 
> Colin wrote:
> 
> Any idea why when trying in LiveCode that the browser widget is near the bottom of the card window?
> 
> BR: No idea.. in fact  that  was the first issue reported in February and even though the preopencard handler issues a
> 
> set the topleft of widget "surpriseBrowser" to 0,0
> 
> did not work.. unless you clicked on the pointer tool and then back on the browser tool. So on a "gut hunch" I did that by script and viola.. it works on desktop, but not on mobile.
> 
> 
> Colin: As an aside, are there any licensing issues involve in getting permission to embed a YouTube video in an app’s web view?
> 
> BR: well since the YouTube App on mobile lets you view *any* you tube.. I wouldn't know why it would require permission. In our case (and in the case of the video in that prototype) Himalayan Academy Publications produced that video on the History of Hindu India (our Part 1 is now up to over a million hits, not bad for a niche publication)  so there should not be any issues. we will see…
> 
> Colin: 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.
> 
> BR: right thanks for reminding me on that score.. I *am* sizing all full screen graphics to 3X4, cropped with the "significant matter" in the middle, so that we don't pillar box on tablets, but I forgot to extend those nav bar group backgrounds… this fullscreenMode "showAll" is really great! just need the browser widget to wake up to the immediate pixel/rect coords/context.
> 
> The browser widget in this case has it's size set to lock location and width and height are fixed in the prop inspector. But somehow the browser widget seems to drop out of the message path, and is unaware of screen orientation changes until you use the select/pointer tool and click on it and then suddenly it wakes up to what has happened.
> 
> I just now tried to change the architecture, created a substack at 736 wide X 414 high, cloned/copy that card to the new substack and tried using an "go stack" button on the main stack. Works on desktop, but the problem still occurs on mobile… and worse: when closing that top substack on mobile, my main stack underneath is shown in landscape instead of jumping back to portrait.
> 
> Some times, as we all know, LC need a little time to let opening operations finish before you attempt too much and short delays can help, so I tried this just now:
> 
> on opencard
> send renderBrowserWidget to me in 500 milliseconds
> send checkBrowserState to me in 3 seconds
> end opencard
> command renderBrowserWidget
> choose pointer tool
> choose browser tool
> set the rect of widget "surpriseBrowser" to 0,0,736,414
> end renderBrowserWidget
> but, again, it does not perform on Mobile….  Hopefully HQ will jump on this, viewing video horizontally is an obvious "must have" requirement and we definitely need to be able to switch, somehow, mid-application. I'm out of hack-a-round ideas so now I am completely blocked for horizontal display of anything via web kit in the app, unless we were to start the app in the orientation and stay lock there.. which is obviously untenable.
> 
> BR
> 
> 
> On Jun 26, 2016, at 6:01 PM, Sannyasin Brahmanathaswami <brahma at hindu.org<mailto:brahma at hindu.org>> 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:…..
> _______________________________________________
> 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