Thanks for responses. I saw the debug mode note, but I am not in
debug mode and it's both the IDE and the standalone. Here's where
the flicker occurs:
1. lock screen
go stack "abc"
go stack "cde" -- a smaller stack that is now in front of
"abc," all other open stacks behind that.
unlock screen -- you clearly see a white flash of stack "abc" ,
then "abc" goes to it's correct appearance, then "cde" appears. I't
as if the
screen was never locked and unlocked. At this point data is
entered into a field on "cde"
2. lock screen
go invisible stack "ghi"
copy contents of various fields on ''ghi" into fields on "abc"
close stack "cde"
close stack "ghi"
open stack "jkl"
end mouseUp -- now it looks just like after the first lock
screen, except "jkl" has replaced "cde" - however the various steps
flash white even though the screen was locked while this took
3. lock screen
close stack "jkl"
palette stack "abc"
end mouseUp -- this time no white flash but "abc" vanishes
briefly and reappears in palette mode. This one I can live with
because there is no white flash, but what did the lock screen
4. (this one is the least important because it is rarely, if ever at
all, used, but I am trying to understand this lock screen thing.)
Screen is as it is after 3 with "abc" in palette mode.
topLevel stack "abc"
go stack "cde" --in one case
go stack "jki" -- the the other case
end mouseUp -- as "abc' goes from palette to topLevel, is
briefly disappers and reappears with very, very slight flash. Again,
buffer is always checked in the inspector.
As I said yesterday, I conquered the same problem eslwhere by
locating the stacks at -5000,-5000, making the changes and then
putting the stacks at their correct locations, but this hasn't worked
for the above, still lots of flashes going on on the screen.
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
> 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
> Well, this is not happeneing here!
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:
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.