On 30-May-07, at 1:18 PM, joe at strout dot net wrote:
> On May 30, 2007, at 18:38 UTC, Charles Yeomans wrote:
>
>> How about refactoring your code so as not to depend on the number of
>> files dropped? I don't really understand why one needs to know this
>> -- perhaps you could offer an example?
>
> Sure; in fact I'll offer two. The first is the real problem I'm
> facing
> today, but the second I think is realistic too.
>
> 1. In Windows, if your app is already running and the user drags a
> batch of files onto it, it should send those file paths to the
> already-running instance (perhaps via an IPCSocket) and then quit. If
> it quits too soon (say, after a single OpenDocument event), then not
> all the documents the user dropped will be opened. If it quits too
> late, then you have a zombie process hanging around that shouldn't be
> there. You really need to quit after processing the last dropped
> file.
>
> 2. Suppose you're making a little droplet (like DropStuff for example)
> whose job it is to combine all the dropped files into a tarball, or
> take a set of images and combine them into a strip or animated GIF.
> Again, you need to know when you have the complete set. You could
> present some UI with the list of files and make the user click a
> "Proceed" button, but what if the user really wants it to Just Do It?
Almost seems that having OpenDocument defined as
OpenDocument(items() as folderItem)
would be preferable or at least as useful.
I think that would work as well wouldn't it ?
Not sure if you implement the "odoc" apple event handler that you
could not intercept the event and figure out how many items there
were and deal with it that way.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|