• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Help with droplet
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with droplet


  • Subject: Re: Help with droplet
  • From: Emmett Gray <email@hidden>
  • Date: Tue, 3 May 2005 09:05:18 -0400

Thanks so much for your help, kai. I now understand how to do this.

I wonder if you or anyone could answer one further question: I am concerned about the possibility that the firstRun and jobQueue properties you propose could be messed up by a force quit or crash, such that their state is saved as false and not null respectively. Can this happen? I tried to make it happen in testing but did not succeed, so it would appear that properties are not saved in an interrupted run and I need not worry. Are properties persistent (i.e. written to disk) only on a normal quit of an applet? Since my process involves potentially overwriting files, I need to be absolutely sure of this behavior.

--Emmett

On Mon, 2 May 2005 23:33:19 +0100, kai <email@hidden> wrote:


On Saturday, April 30, 2005, at 04:07  pm, Emmett Gray wrote:

 I have a working droplet app which processes one or more dropped files
 or folders, and on launch shows a dialog, and then after the process
 terminates, shows another dialog offering to open the logfile(s) it
 wrote or just quit. I am trying to turn it into an AS Studio app so as
 to allow it to accept more stuff to process while it is already
 running; as a pure AS droplet, once launched it won't recognize
 another drop.

 The ASS version is working sort of, but essentially shows the second
 drop in a second dialog box as if I had launched another copy of the
 application. This would be OK except that on termination, when I
 dismiss the first dialog, it is telling the app to quit and this
 causes a crash because the second process is still active (even if
 just showing its dialog). I do want the app to quit when it's done
 with everything and not stay open.

 What I'd really like to do and can't conceptually figure out is how to
 simply append to the list of items to process rather than create a new
 list with the second drop, and how to skip the opening dialog for
 subsequent drops, and then how to terminate with a combined dialog for
 everything. Specifically what I don't get is how to construct a
 mechanism for the app to distinguish between "on open" for the first
 run and "on open" for additional drops, like using a property or a
 global or writing to a file or something. How would that get reset for
 a new launch and modified for additional drops? If I use a file, how
 would I clean up if there's a crash or interruption and the file
 doesn't get deleted?

 If this is difficult or complicated, I'd be satisfied just to
 understand how to use the idle handler to determine whether or not
 there is still a process running and to tell the app to quit when
 there is not.

 With either approach, I still see a potential problem in the situation
 when the app is showing its final dialog (perhaps in the background)
 and another drop happens at that point. Maybe the idle routine could
 handle that situation and treat it as a whole new launch.

 Maybe I'm not thinking about this in the right way. Any help is
 appreciated, including a pointer to RTFM.

A stay-open script application should handle incoming commands even if it is already running a handler in response to a previous command, Emmett - so it might be worth exploring further.

One significant difference between a stay-open app and a regular
applet/droplet is that the former requires an explicit quit command -
while the latter quits automatically once its work is done.

Although the following script may not do exactly what you want, it
contains examples of a 'firstRun' flag, a dynamic 'jobQueue' (to which
new, incoming lists may be added), an idle handler - and a quit handler
(including a 'continue quit' command). Once the final dialog has
appeared, it's not easy to process or store added items before
quitting. However, clicking the "Wait" button will avoid an immediate
quit so that any latecomers can be included (once the specified
'idleTime' has elapsed):

-----------------

property firstRun : true
property idleTime : 10 (* modify as required *)
property jobQueue : {}

to processJobQueue()
	repeat until (count jobQueue) is 0
		set currItem to jobQueue's item 1

		------------------------------------
		(* do something with currItem here *)
		------------------------------------

		set jobQueue to rest of jobQueue
	end repeat
end processJobQueue

to doFirstRun(newItems)
	set firstRun to false
	activate
	try
		display dialog "Process the dropped item(s)?" with icon 1
		set jobQueue to jobQueue & newItems
		processJobQueue()
	on error number -128 (* user cancelled *)
		quit
	end try
end doFirstRun

on open newItems
	if firstRun then
		doFirstRun(newItems)
	else
		set jobQueue to jobQueue & newItems
	end if
end open

on run (* just in case *)
	display dialog ¨
		"Drag any item(s) to be processed onto my icon." buttons ¨
		{"OK"} default button 1 with icon 0
	quit
end run

on idle
	if (count jobQueue) > 0 then processJobQueue()
	activate
	set nextAction to (display dialog ¨
		"Quit now?" buttons {"Wait", "Quit"} ¨
		default button 2 with icon 1)'s button returned
	if nextAction is "Quit" then
		quit
		1
	else
		idleTime
	end if
end idle

on quit
	set firstRun to true
	continue quit
end quit

-----------------

---
kai

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Help with droplet
      • From: kai <email@hidden>
  • Prev by Date: (no subject)
  • Next by Date: XMLRPC Apple Event --- Sending base64 data
  • Previous by thread: Re: Help with droplet
  • Next by thread: Re: Help with droplet
  • Index(es):
    • Date
    • Thread