lock screen
Scott Rossi
scott at tactilemedia.com
Wed Jun 15 05:49:08 EDT 2005
Recently, Lars Brehmer wrote:
> from the docs:
>
> A handler may need to open a stack and then close it before the
> handler is completed, or to move or change the appearance of a number
> of objects on the screen. If the screen is locked before these
> changes occur, the user does not see the changes happen on screen.
> Locking the screen can prevent user confusion or unsightly screen
> flashing. It also increases the speed of the handler, since
> Revolution does not have to redraw all the intermediate states of the
> screen.
>
> Well, this is not happeneing here!
Hi Lars:
First of all, locking the screen doesn't affect the entire screen, it
affects the display of the contents of the default stack. So if you lock
the screen, you can still move stacks around the screen and hide/show them,
but any updates to the *contents* of the default stack will not be visible
until the current handler ends you call unlock screen. Lock screen is often
used when initializing a stack's objects, populating objects with content,
or employing a visual effect, such as:
lock screen
go next card
unlock screen with visual dissolve
Locking screen will not get rid of any split-second flash that may be
visible before a stack is opened or made visible.
All this being said, in my own work I am encountering what I think is an
intermittent positioning bug where trying to set a stack's location to
something outside the screenRect will fail and a white flash flash equal to
the screen's rect will be briefly visible before the stack is drawn. But I
haven't been able reproduce this consistently.
FWIW, the only way I know to get rid of any flash before displaying a stack
is to use Trevor DeVore's window external and making a stack transparent
before showing it. I believe this only works on OSX currently.
Regards,
Scott Rossi
Creative Director
Tactile Media, Multimedia & Design
-----
E: scott at tactilemedia.com
W: http://www.tactilemedia.com
More information about the use-livecode
mailing list