Thanks for your fine explanation. And the future handlers sound very promising,
both OnUpdate() and OnMarksPonder().
Graphics are meanwhile pretty fast in LCB. I timed such clock updates (in LCB):
The OnPaint of a clock needs, also with a heavy loaded CPU, less than 4
millisecs.
Even checking the
On 2017-08-22 17:31, hh via use-livecode wrote:
@Mark.
Say I have 24 copies of the LC clock widget in order to display
different time zones.
How can I have them in "seconds-sync"?
In LC Script, with LCS-clocks I would do a screenLock, update the
clocks and then unlock.
In LC Builder I even tried
@Mark.
Say I have 24 copies of the LC clock widget in order to display different time
zones.
How can I have them in "seconds-sync"?
In LC Script, with LCS-clocks I would do a screenLock, update the clocks and
then unlock.
In LC Builder I even tried to make a composed widget, without improvement.
The general consensus is that it doesn't. I think there was something else
going on where my screen was not updating even after 5 successive screen
unlocks, and I never figured out why, but I went through my app and every place
there was a lock screen, I added an unlock screen to the end of the
On 2017-08-22 04:41, hh via use-livecode wrote:
The real interesting thing is now for me how to lock the screen
in LC Builder? I couldn't find a way to do that. Who knows?
There isn't one - although you can use 'execute script' to use LCS's
lock/unlock screen.
Indeed, I should check whether
The real interesting thing is now for me how to lock the screen
in LC Builder? I couldn't find a way to do that. Who knows?
This interacts with LC Script, timed widgets (clocks, animations)
want their own screen updates ...
___
use-livecode mailing lis
On 08/21/2017 10:28 AM, Mark Waddingham via use-livecode wrote:
On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:
Except when it doesn't. There seems to be an override in the lock
count if any unlock uses a visual effect. I'm not sure if that's on
purpose or not.
Internally there is
On 8/21/17 5:47 PM, prothero--- via use-livecode wrote:
I didn't realize that the lockscreen command only applied to the handler that
sets it.
No, it doesn't (or shouldn't) apply only to the handler that sets it.
Does this mean that each script has to set lockscreen if it needs it?
It's a
This exactly. Globally on or globally off. Just unlock and lock again to update.
It is moot, but I would prefer it.
Sent from my iPhone
> On Aug 21, 2017, at 6:47 PM, prothero--- via use-livecode
> wrote:
>
> I didn't realize that the lockscreen command only applied to the handler that
> set
I didn't realize that the lockscreen command only applied to the handler that
sets it.
Does this mean that each script has to set lockscreen if it needs it? If
lockscreen was either globally true or not, you could do:
On doscreenstuff1
Set lockscreen to true
Handler1
Handler2
On 8/21/17 1:28 PM, Jonathan Lynch via use-livecode wrote:
I agree with Bill. If you lock a door twice on a car, it is still just locked.
One unlock will open it up. That seems more intuitive.
Initially it's more intuitive, but if it were done this way you couldn't
have handlers that manage l
I agree with Bill. If you lock a door twice on a car, it is still just locked.
One unlock will open it up. That seems more intuitive.
Sent from my iPhone
> On Aug 21, 2017, at 2:19 PM, prothero--- via use-livecode
> wrote:
>
> Seems like it would be much simpler if lockscreen just kept the s
Seems like it would be much simpler if lockscreen just kept the screen locked
until unlockscreen was invoked, but there was an update screen command when
forced updates were needed. No counters to keep track of.
Best
Bill
William Prothero
http://ed.earthednet.org
> On Aug 21, 2017, at 10:40
I used to have an example, I struggled with the problem until I figured out
the reason, and then I modified the script to work around it. It actually
didn't happen in the IDE, only on Android. (I didn't test on iOS.) Now I
can't remember what the original problem script was. But I'll see if I ca
I would have to recreate it as my production stack has already been gone
through, and it seems to be working as advertised, which would argue against it
being an engine issue. I'll see if I can create a sample stack in the next
couple days. Right now I have a couple service calls to go out on an
On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:
Except when it doesn't. There seems to be an override in the lock
count if any unlock uses a visual effect. I'm not sure if that's on
purpose or not.
Internally there is a counter - and only one - the engine uses it too
when it needs
I was hoping for a command that left the screen lock set but forced an update
of the screen. That way I wouldn't have to unlock/relock and depend on there
only being one screen lock pending.
Bob S
> On Aug 21, 2017, at 08:51 , J. Landman Gay via use-livecode
> wrote:
>
> I was unaware of t
I was unaware of that too. It doesn't sound right.
On August 21, 2017 10:10:27 AM Bob Sneidar via use-livecode
wrote:
Yup. My troubles came when I had a handler unlock the screen 5 times
straight and I do not lock the screen to that many levels. It still did no
unlock the screen, so now i
Hi Bob - just an idea for a progress indicator - you could advance a progress
indicator through a browser widget. This would work even when the screen is
locked, allowing you to show progress while not having unlock and lock each
time.
The widget requires a fair bit of overhead, so that might n
Yup. My troubles came when I had a handler unlock the screen 5 times straight
and I do not lock the screen to that many levels. It still did no unlock the
screen, so now it may be that one handler cannot unlock another handler's lock
screen, which I was unaware of.
Bob S
> On Aug 18, 2017, a
On 08/18/2017 07:41 PM, J. Landman Gay via use-livecode wrote:
Except when it doesn't. There seems to be an override in the lock count
if any unlock uses a visual effect. I'm not sure if that's on purpose or
not.
Thanks. Good to know. I've just been using the barebones lock.
--
Mark Wieder
Except when it doesn't. There seems to be an override in the lock count if
any unlock uses a visual effect. I'm not sure if that's on purpose or not.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 18,
On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote:
Hard to say. I'm almost done finding every place I lock the screen and adding
an unlock screen in the same handler.
And that, of course, is the best procedure. Locking/unlocking the screen
works on sort of a reference-counting approa
Hard to say. I'm almost done finding every place I lock the screen and adding
an unlock screen in the same handler.
Bob S
> On Aug 18, 2017, at 14:03 , J. Landman Gay via use-livecode
> wrote:
>
> That doesn't sound right, though I've seen issues with nested locks too. What
> happens if yo
That doesn't sound right, though I've seen issues with nested locks too.
What happens if you call this handler:
on unlockReally
repeat until the lockscreen is false
unlock screen
end repeat
end unlockReally
On 8/18/17 3:54 PM, Bob Sneidar via use-livecode wrote:
okay after some testin
okay after some testing it seems only the script that locked the screen, maybe
only the actual handler can clear it's own lock. If this is not right I'd like
to know it. Seems there ought to be an unlock all command or some such thing.
Bob S
> On Aug 18, 2017, at 13:37 , Bob Sneidar via use-l
Hi all.
I have some screen updates I do that take time because I query a database
first, and it may not be local. To keep the screen from progressively updating,
I lock the screen.
I then decided to put a status message field at the bottom of each "form"
(meaning card in a stack) so I have a
27 matches
Mail list logo