>>
>>
>> I have one design issue that I am sure will cause some to say **
>> ouch**, but it **seems** to work. In order to give the user a chance
>> to cancel a part of the program, (with the sorting etc carried out in
>> a thread, I set a timer in a non-thread class ( to single mode) which
>> triggers a Dialog, then suspend the thread. The period for the Timer
>> seems long enough that the suspended thread occurs before the Dialog.
>> If there are other ways to do this, then I would like to hear those.
>> BTW...polling the thread is a great technique and works great. A
>> huge
>> downside of this approach is that the duplicate mails are moved by RB
>> and are placed in a folder that Mail does not know about. Rebuilding
>> Mail is easy, but not elegant.
>
> I can't exactly picture what is happening here, but a dialog to cancel
> a long winded operation isn't that uncommon a requirement.
It is not really a dialog to cancel an operation, more a dialog to ask
if the application should implement "part 2" ie doing something ( in
this case , moving) files that
> I would
> just let the thread loop as is necessary but every check through the
> loop check a global or other variable like "TheUserHasCancelled as
> boolean" and if that turns to true then stop what you're doing. In a
> button on your modal dialog set the value to true if they click. I may
> have totally misunderstood why you had to do what you did though, so
> send more info if necessary ;)
>
>>
>>
>> Next issue regards another approach. It is possible to use
>> AppleScript
>> in a loop to move e-mails within Mail. But the loop seems to
>> "outpace"
>> Mail's ability to respond, or perhaps AppleScript ability to help. So
>> has anyone else experienced this. If so, can one "Slow down" the
>> loop?
>> Perhaps feedback from Mail that an action has occured.
>>
>
> An applescript should wait for the app being scripted to finish the
> command before moving onto the next command. Unless you have it in a
> loop of "ignoring application responses" in which case it will just
> queue up the events as fast as possible and give the app a heart
> attack.
>
> Another possibility is to not do the loop in applescript at all but
> just a single move. And then call the script repeatedly with the new
> data each time from your RB app. That will also give you the
> opportunity to cancel it by being able to check again for the user
> cancelled value between each one too.
>
>
> Thanks,
> James
>
>
> James Sentman http://sentman.com
> http://MacHomeAutomation.com
>
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|