On May 30, 2007, at 3: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.
Can't help with this...
>
> 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?
Just Do This.
<http://www.declaresub.com/file_download/17>
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
From Wed 30 May 2007 14:18:37 -0600
Return-Path: <realbasic-nug-bounces at lists dot realsoftware dot com>
X-Original-To: listarchive at realsoftware dot com
Delivered-To: listarchive at realsoftware dot com
Received: by xmail.realsoftware.com (Postfix, from userid 1037)
id 60FDC29A3970; Wed, 30 May 2007 13:18:46 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
www.realsoftware.com
X-Spam-Level:
X-Spam-Status: No, score=-3.0 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00,
NO_REAL_NAME autolearn=ham version=3.1.1
Received: from lists.realsoftware.com (m.realsoftware.com [66.116.103.65])
by xmail.realsoftware.com (Postfix) with ESMTP id 7740129A3966;
Wed, 30 May 2007 13:18:45 -0700 (PDT)
Received: from real-software-mini.local (localhost [127.0.0.1])
by lists.realsoftware.com (Postfix) with ESMTP id 88E50331B20;
Wed, 30 May 2007 15:18:38 -0500 (CDT)
X-Original-To: realbasic-nug at lists dot realsoftware dot com
Delivered-To: realbasic-nug at lists dot realsoftware dot com
Received: from mail.verex.com (mail.verex.com [66.116.103.197])
by lists.realsoftware.com (Postfix) with ESMTP id D1DAC331B15
for <realbasic-nug at lists dot realsoftware dot com>;
Wed, 30 May 2007 15:18:34 -0500 (CDT)
Received: from [66.116.103.197] (localhost [127.0.0.1])
by mail.verex.com (Postfix) with SMTP id D390575C0EC
for <realbasic-nug at lists dot realsoftware dot com>;
Wed, 30 May 2007 14:18:37 -0600 (MDT)
Date: Wed, 30 May 2007 14:18:37 -0600
Subject: Re: feedback ID for detecting last file drop?
From: joe at strout dot net
To: realbasic-nug at lists dot realsoftware dot com
In-Reply-To: <F08419EE-4D22-4C68-A26E-898CA7F501F0 at great-white-software dot
com>
X-Mailer: VerEx Email Gateway
Message-Id: <20070530201837 dot D390575C0EC at mail dot verex dot com>
X-BeenThere: realbasic-nug at lists dot realsoftware dot com
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: realbasic-nug-bounces at lists dot realsoftware dot com
Errors-To: realbasic-nug-bounces at lists dot realsoftware dot com
On May 30, 2007, at 19:48 UTC, Norman Palardy wrote:
> Almost seems that having OpenDocument defined as
>
> OpenDocument(items() as folderItem)
>
> would be preferable or at least as useful.
Yes, that's one (new-feature) solution that's been proposed in the
past. The drawback is that it breaks existing code. Another solution
would be to define it as
OpenDocument(item as FolderItem, allItems() as FolderItem)
for backwards-compatibility, or even something like
OpenDocument(item as FolderItem, moreToCome as Boolean)
although that last parameter should be "moreComin'" but that wouldn't
be valid syntax.
> 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.
Yes, I'm pretty sure you can, but I'm looking for a cross-platform
solution.
Best,
- Joe
--
Joe Strout -- joe at strout dot net
Strout Custom Solutions
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|