Page 1 of 1

buffering browser widget

Posted: Mon Jul 15, 2019 5:39 pm
by hopkins
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

Re: buffering browser widget

Posted: Mon Jul 15, 2019 7:06 pm
by bogs
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

Re: buffering browser widget

Posted: Mon Jul 15, 2019 7:17 pm
by dunbarx
What bogs said.

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
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;

Code: Select all

repeat until the lockScreen is "true"
  lock screen
end repeat

Re: buffering browser widget

Posted: Mon Jul 15, 2019 7:27 pm
by hopkins
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.

Re: buffering browser widget

Posted: Mon Jul 15, 2019 8:02 pm
by [-hh]
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.

Re: buffering browser widget

Posted: Mon Jul 15, 2019 8:30 pm
by hopkins
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.

Re: buffering browser widget

Posted: Mon Jul 15, 2019 10:52 pm
by dunbarx
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

Re: buffering browser widget

Posted: Mon Jul 15, 2019 11:59 pm
by hopkins
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.