Richard,
I like that! :-D
>
> My WebMerge product has a similar challenge: for most folks it runs in just
> a few seconds, but it's sometimes used to process very large collections of
> product lists (300,000 or more) which can take a few minutes.
>
> So I needed both a way to indicate progress, and a way to cancel the task,
> just as you do.
>
> Here's what I did:
>
> In the main repeat loop I have a call to a CheckCancel handler, e.g.:
>
> ...
> global gProcessActive
> put true into gProcessActive
> show button "Cancel"
> --
> repeat for each line tLine in tData
> CheckCancel
> --
> Processs tLine
> end repeat
> ...
>
> Here's the CheckCancel handler:
>
> on CheckCancel
> global gProcessActive
> wait 0 with messages
> if gProcessActive <> true then
> DoCleanUpAndExit
> else
> ShowProgress
> end if
> end CheckCancel
>
> Then in a button labeled "Cancel" I have this script:
>
> on mouseUp
> global gProcessActive
> put false into gProcessActive
> end mouseUp
>
>
> So first the gProcessActive flag is set before entering the loop, and within
> the loop CheckCancel is called to do two things:
>
> 1. Allow messages to be sent ("wait 0 with messages")
> 2. Check if the flag has been set to false
>
> Because messages are processed thanks to the "with messages" modifier, if
> the user clicks on the "Cancel" button that button's script sets the flag to
> false, and the next call to CheckCancel will notice that and call
> DoCleanUpAndExit if it needs to.
>
> What happens in DoCleanUpAndExit will of course depend on what your program
> is doing (though you should include a "exit to top" statement to exit the
> loop from outside of it), and the same is true for ShowProgress. Because
> WebMerge's process is of a knowable length (the number of lines of the data
> it's working on) I use a progress bar, but you could use a spinning wheel or
> indeterminate progress bar or even just updating text in a field, whichever
> works for your UI.
>
> I've experimented with various methods of canceling long processes, and thus
> far this solution based around "wait 0 with messages" has shown itself to
> require the least overhead of the options I've tried.
>
> HTH -
>
> --
> Richard Gaskin
> Fourth World
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
>
> _______________________________________________
> 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
>
--
http://www.andregarzia.com All We Do Is Code.
_______________________________________________
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
