"lock screen" issues

[Wilhelm Sanke]

Recently I had some experiences with "lock screen" that might possibly
be interesting to other Metacard users.

There are instances when "lock screen" or "set the lockscreen to true"do
not lock the screen entirely.

- When the values for the thumbs of a scrollbar are reset in a script
with a preceding "lock screen" , the scrollbar interestingly  shows
*two* thumbs at the same time, the old one with the corresponding
numeric values and the new one without showing the numbers. Only after
the handler has finished  the new thumb position together with the new
number value is shown.

Of course, it is no problem to set "lock screen" later in the script,
but I find it worth mentioning that this command does apparently not
fully lock the screen.

- When scanning the color pixels of an image (don't ask why you should
do this) using "screenmouseloc" and "mousecolor", the quick movement of
the cursor can be seen despite setting "lock screen" in the handler.
In this instance  you need to "set the cursor to none" to prevent this
movement being seen during "lock screen".

- I did not know that it is possible to "double-lock" the screen, which
then has to be unlocked likewise by a double unlock. Usually,
double-locking , which I did inadvertently, has no effect, because
unlocking occurs anyway at the end of a button script.

However - and this is how I noticed this behavior - if you call such a
button with "send mouseup" from another handler, say even from a repeat
loop, and you do not carefully unlock both (or the one lock if you have
only one) you have to wait until the repeat loop has finished, because -
as the item in the help reference says -  "This property is reset to
false when all pending handlers have finished executing", which
statement acquired a new meaning to me. The repeat loop in this case had
an average duration of 10 minutes, which I happily was able to interrupt
with an inbuild control-key statement.

Speed issues:

The help reference states "Locking the screen before changing ...
properties of several objects, may improve performance ...".

This is true in most instances. For instance in a graphics application
that produces color patterns I use "lock screen" and "unlock creen" to
display whole horizontal lines or vertical columns of background colors
of graphics or fields at a time, which produces a nice horizontal or
vertical visual effect that is carried out with extreme speed.
However, (coming to the "may" in the reference) when I display
"diagonal" columns - as it were - of the new field colors with "lock
screen" and "unlock screen" for each  column, the performance slows down
considerably, i.e. the performance is noticeably slower than without
using lockscreen  (under Windows 98 for about 2 seconds slower for a
number of 3000 color fields or graphics).

Here is part of the script that causes such a slowdown:

It is for the middle part of  a color matrix of 45 X 60 fields, where
"re" is the width of the matrix, and the new colors have been set
previously in the newcolor-array.

"put 60 into re
repeat with fn = 1 to 15
    put -1 into i
    put fn into j
    lock screen
    repeat with w = 1 to 45
      add 1 to i
      add 1 to j
      set the backcolor of fld (i*re + j) to  newcolor[i,j]
    end repeat
    unlock screen
  end repeat"

I am  really at a loss to understand why the performance of the handler
is so much slower  in this case than with strictly vertical or
horizontal adjacent fields. The script for the purely horizontal or
vertical fields is more or less the same, differing only in the "add 1
to i" and "add 1 to j" for the diagonal progression of fields.

Any explanations or comments?

Regards,

Wilhelm Sanke