I wonder if you cannot manage to lock the screen over more than one
handler by calling
the second handler from within the first one?
For instance:
on mouseDown
set the lockscreen to true
put "screen locked"
send "mouseStillDown" to me
wait 10 ticks
set the lockscreen to false
end mouseDown
on mouseStillDown
put "pigs have wings"
end mouseStillDown
Just a thought.
Richmond.
On 7/6/17 12:49 pm, Tiemo Hollmann TB via use-livecode wrote:
I think I now tried all combinations with a separate frameless browser for the
player object, with and without locking the screen and locking the mesages, but
the behavior of the player object and it's control over the main window frame
obviously can't be controlled by LiveCode (at least not by me).
Am I right that I don't have control over the colour of the main window frame?
Perhaps I'll find a tweak tool for Windows 8, to give it the look & feel of
Windows 10, which I can recommend my customers, where the flickering isn't that
distracting.
Tiemo
-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von
Tiemo Hollmann TB via use-livecode
Gesendet: Mittwoch, 5. Juli 2017 18:46
An: 'How to use LiveCode' <use-livecode@lists.runrev.com>
Cc: Tiemo Hollmann TB <toolb...@kestner.de>
Betreff: AW: can I lock screen over more than one handler?
Hi Randy,
it worked out that the issue wasn't related to the design of two handlers and
it was only the single statement for setting the filename to the player object
in one handler. But it seems, I can't suppress the loosing and reassigning of
the focus of the main window when setting the filename. With and without
locking the screen.
What I didn't tried yet is placing the player object into an own window without
title bar and frame. I don't know, how that looks on Windows 8, but perhaps I
can keep the flickering off the main window with that approach.
Tiemo
-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von
Randy Hengst via use-livecode
Gesendet: Mittwoch, 5. Juli 2017 17:56
An: How to use LiveCode <use-livecode@lists.runrev.com>
Cc: Randy Hengst <iowahen...@mac.com>
Betreff: Re: can I lock screen over more than one handler?
It’s been a long time since I’ve messed with player objects… but what about
putting both of the handlers into a “run” handler:
on runMyHandlers
LOCK SCREEN
handler1
handler2
UNLOCK Screen
end runMyHandlers
On Jul 5, 2017, at 10:42 AM, Tiemo Hollmann TB via use-livecode
<use-livecode@lists.runrev.com> wrote:
Jonathan had a tricky idea to work with two player objects switching
between them with hiding and showing them and doing the assignment of
the filename with the currently hidden player, even with locking the
screen at the beginning of the handler.
It's a pitty, but the flickering of the whole window frame keeps the same.
The directShow video engine must be somehow totally dominant.
Any other tricky idea?
Tiemo
-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im
Auftrag von Tiemo Hollmann TB via use-livecode
Gesendet: Mittwoch, 5. Juli 2017 15:57
An: 'How to use LiveCode' <use-livecode@lists.runrev.com>
Cc: Tiemo Hollmann TB <toolb...@kestner.de>
Betreff: AW: can I lock screen over more than one handler?
Thanks Jonathan, Trevor and Sean for your comments.
Meanwhile I could drill down my "flickering" problem (post from
yesterday) to an unexpected command.
In one of those handlers I "set the filename of player "myVideoPlayer"
to tFile". This command withdraws the focus from the window and passes
it back after some milliseconds. On my Win 10 machine with a white
window title bar I almost can't see it, but on Win 8 with the standard
violet title bar it is an ugly flickering, each time I set the
filename (which happens very frequently in a quiz loop).
And I can't prevent this flickering with a lock screen right before
the setting of the filename. The setting of the filename seems to
release the lock screen or it takes the focus of the window off and
back. Very ugly in my case.
Tiemo
-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im
Auftrag von Sean Cole (Pi) via use-livecode
Gesendet: Mittwoch, 5. Juli 2017 15:30
An: How to use LiveCode <use-livecode@lists.runrev.com>
Cc: Sean Cole (Pi) <s...@pidigital.co.uk>
Betreff: Re: can I lock screen over more than one handler?
Hi Tiemo,
The solution here is to call another lockScreen at the beginning of
handler2. You don't have to use the unlockScreen at the end of handler
1 and
2 as it will do that automatically but it is advisable to include the
command anyway. Is there a reason why you had an aversion to using a
lockScreen at the start of handler2?
All the best
Sean Cole
*Pi Digital Productions Ltd*
On 5 July 2017 at 14:09, Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:
On Wed, Jul 5, 2017 at 6:45 AM, Tiemo Hollmann TB via use-livecode <
use-livecode@lists.runrev.com> wrote:
Is this possible?
on handler1
lock screen
-- do some stuff here
send "handler2" in 0 milliseconds
end handler1
on handler2
-- do some other stuff here
unlock screen
end handler2
No it is not. From the docs for `lock screen`:
"When all pending handlers are finished executing, the lockScreen
property is set back to false and the user sees the current state of
stack windows on the screen."
The use of the word "pending" is confusing because when you use
`send` you end up with an entry in the `pendingMessages`. But the
screen is going to be unlocked each time through the event loop. If
`handler` called `handler2` directly (without using `send`) then you
would not see the screen update. You should see the result you are
looking for if you change your code to look like this:
```
on handler1
lock screen
-- do some stuff here
handler2
end handler1
```
If you need to call `handler2` in time then you will need to figure
out another approach to updating the screen. Perhaps all screen
updates will need to happen in `handler2`.
--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
