buffering browser widget
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
buffering browser widget
Hi,
I use a browser widget to display an image grid (sending it html code). The html code with the image links is displayed quickly. Clicking on a image opens another card. When I return to the first card with the widget, there is a delay for the widget to be displayed completely. I would expect that one could "buffer" the page as in a browser, so that when you return to it it is displayed instantaneously.
Is there anyway of "buffering" the widget so that navigation is smoother ? Does locking the screen help, if so, how should it be unlocked - in the widgt's script ?
EDIT: I added this to the browser script, and it helps, but is still slower than exepected.
on browserFrameDocumentLoadComplete
unlock screen
end browserFrameDocumentLoadComplete
I use a browser widget to display an image grid (sending it html code). The html code with the image links is displayed quickly. Clicking on a image opens another card. When I return to the first card with the widget, there is a delay for the widget to be displayed completely. I would expect that one could "buffer" the page as in a browser, so that when you return to it it is displayed instantaneously.
Is there anyway of "buffering" the widget so that navigation is smoother ? Does locking the screen help, if so, how should it be unlocked - in the widgt's script ?
EDIT: I added this to the browser script, and it helps, but is still slower than exepected.
on browserFrameDocumentLoadComplete
unlock screen
end browserFrameDocumentLoadComplete
Re: buffering browser widget
If you lock the screen, my understanding is that you have to unlock it as well for as many locks as you put in. The dictionary example illustrates this I think pretty well...
on mouseUp
lock screen -- first lock
drawStuff -- gets locked again and unlocked in drawStuff
show image "Sprite"
unlock screen -- now unlocked - 2 locks balanced by 2 unlocks
end mouseUp
on drawStuff
lock screen -- screen now locked twice
show field "Notify"
unlock screen -- not unlocked yet - locked twice, unlocked once
end drawStuff
-
- VIP Livecode Opensource Backer
- Posts: 9579
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: buffering browser widget
What bogs said.
This has been true since 1987 HC. Back in the day, since there is not a function "theNumberOfLocks", we used to:
This way you did not have to count locks, which might occur in various places including called handlers and functions.
Craig
Silly Edit: It only just occurred to me now, 32 years later, how pointless it is to have;
This has been true since 1987 HC. Back in the day, since there is not a function "theNumberOfLocks", we used to:
Code: Select all
repeat until the lockScreen is "false"
unlock screen
end repeat
Craig
Silly Edit: It only just occurred to me now, 32 years later, how pointless it is to have;
Code: Select all
repeat until the lockScreen is "true"
lock screen
end repeat
Re: buffering browser widget
thanks. I was aware of how lock / unlock works. Was just wondering if there is anything else to do to buffer a browser widget. My question may not have been very clear.
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: buffering browser widget
Locking the screen may not help with that: the delay is probably from switching cards and the fact that the browser widget uses a native display.
You could try to stay always on the same card and hide/show the linked image and show/hide the widget instead.
You could try to stay always on the same card and hide/show the linked image and show/hide the widget instead.
shiftLock happens
Re: buffering browser widget
I was afraid that would be the answer - it is simpler to switch cards then manage everything on one, but will give it a shot.
-
- VIP Livecode Opensource Backer
- Posts: 9579
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: buffering browser widget
Hi.
Hermann's idea is made more palatable when you put each "card's" worth of controls in a group, and simply hide and show groups. This could be indistinguishable from navigating to actual other cards. You might set custom properties to distinguish one group from another, so that you can reuse code. There are lots of tricks...
No other functionality need be ascribed to such groups if you don't need to; they are just vehicles to get you, er, going.
Craig
Hermann's idea is made more palatable when you put each "card's" worth of controls in a group, and simply hide and show groups. This could be indistinguishable from navigating to actual other cards. You might set custom properties to distinguish one group from another, so that you can reuse code. There are lots of tricks...
No other functionality need be ascribed to such groups if you don't need to; they are just vehicles to get you, er, going.
Craig
Re: buffering browser widget
I will work with groups. Oddly, setting the visibility of a group in which there is a browser widget is not sufficient, the widget itself has to be hidden as well.