quickly wiping a card

Geoff Canyon gcanyon at gmail.com
Sun Sep 15 23:33:11 EDT 2013


Scott, that runs in about 6ms for me, and the only things faster I could
find were to make sure the objects were in a group and delete the group (as
you suggested) or just create a new blank card and delete the existing
card, and neither of those was faster than 4ms.


On Sun, Sep 15, 2013 at 8:08 PM, Scott Rossi <scott at tactilemedia.com> wrote:

> 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" <mwieder at 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
> > mwieder at ahsoftware.net
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list