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 <sc...@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" <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 > _______________________________________________ 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