Hi Mark:
My point was, with messages locked, nothing can be updated until after the
handler has executed (or you manually unlock messages). So if your
scripts rely on tracking objects individually as they are deleted, then
locking messages doesn't make sense. However, the original post
explicitly mentioned clearing a card as quickly as possibly, and in this
case, locking messages can make a substantial difference. Otherwise, the
IDE will track each object as it is deleted. For example:
-- CREATE A COLLECTION OF GRAPHICS:
-- RUNS HERE MORE THAN 2x FASTER
-- WITH MESSAGES LOCKED
on mouseUp
set style of the templateGraphic to "oval"
set width of the templateGraphic to 200
set height of the templateGraphic to 200
set loc of the templateGraphic to loc of this cd
put millisecs() into MS
lock screen
lock messages
repeat 5000
create grc
end repeat
unlock messages
unlock screen
put millisecs() - MS
reset the templateGraphic
end mouseUp
-- DELETE A COLLECTION OF GRAPHICS:
-- RUNS NEARLY INSTANTANEOUSLY HERE
-- WITH MESSAGES LOCKED, COMPARED TO
-- MORE THAN 3 SECONDS WITHOUT
on mouseUp
put millisecs() into MS
lock screen
lock messages
repeat number of grcs
delete grc 1
end repeat
unlock messages
unlock screen
put millisecs() - MS
end mouseUp
----------
A couple of other tricks I use when creating or deleting numerous objects
(call it
a "collection" for the sake of discussion):
1) To delete a collection instantaneously at any time, I often create the
objects of the collection inside a group. When I want to delete the
collection, I only need to delete the group in a single action, as opposed
to using a repeat loop on individual objects.
2) When creating or deleting large collections while in the IDE, I close
the Application Browser. This stack continually tracks objects in a
development stack, so closing it can speed up object creation/deletion
time.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
On 9/15/13 4:26 PM, "Mark Wieder" <mwie...@ahsoftware.net> wrote:
>Scott-
>
>Saturday, September 14, 2013, 7:23:35 PM, you wrote:
>
>> Actually Mark, locking messages is often a good way to speed things
>> exactly because the IDE doesn't track objects that are added or deleted
>> until after the current handler has finished executing.
>
>Well, you had me going for a while there, but no. If you lock messages
>the IDE doesn't get the delete<object> message at all. This is what
>lock messages is supposed to do. Try this:
>
>in a frontscript put
>
>on deletefield
> put "deleting" & cr after msg
> deletefield
> pass "deletefield"
>end deletefield
>
>Then create a new mainstack with a button and a field.
>In the button script put
>
>on mouseUp
> delete field 1
>end mouseUp
>
>OK - now that you can see the "deleting" message in the message box,
>put a new field on the stack again and change the mouse script to
>
>on mouseUp
> lock messages
> delete field 1
> unlock messages
>end mouseUp
>
>So yes, locking messages *is* a good way to speed things up in the
>proper situations, e.g., if you're doing this in a standalone you'll
>gain a significant boost, but there might be side effects if you try
>this in the IDE.
>
>--
>-Mark Wieder
> mwie...@ahsoftware.net
_______________________________________________
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
