Well, other than saying "one could argue it's the failure of these
digital asset managers..." to suggest that there are missing
features. :)
And having a nil dragSource makes sense if the source and destination
for the drag are in different processes. The drag source is an object
(type id
On Mar 26, 2010, at 11:31 AM, Jens Alfke wrote:
>
> On Mar 26, 2010, at 7:40 AM, Jeffrey J. Early wrote:
>
>> They actually don't have to be inside the library bundle... there's an
>> "Advanced" preference to not copy the original into the library.
>
> In that case, the image file would be vis
On 26 Mar 2010, at 14:43, Jeffrey J. Early wrote:
> Gotcha -- sorry if I read into that a bit much.
>
> I haven't complained this as a missing feature here at all yet -- I was
> actually still under the impression that there was a mechanism to determine
> the drag source that I didn't know abo
On Mar 26, 2010, at 7:40 AM, Jeffrey J. Early wrote:
> They actually don't have to be inside the library bundle... there's an
> "Advanced" preference to not copy the original into the library.
In that case, the image file would be visible to other apps. So I might have
dragged the photo from t
Gotcha -- sorry if I read into that a bit much.
I haven't complained this as a missing feature here at all yet -- I was
actually still under the impression that there was a mechanism to determine the
drag source that I didn't know about. As the consensus appears to be that there
isn't, I will f
On Mar 26, 2010, at 10:23 AM, Jens Alfke wrote:
>
> On Mar 26, 2010, at 7:00 AM, Jeffrey J. Early wrote:
>
>> When a user drags a photo from iPhoto to my application I need to be able to
>> update iPhoto's database (via ScriptingBridge) with changes that are made
>> while in my program.
>
>
I wouldn't say that there has been any argument over whether or not
knowing the drag source is a good thing; we were simply asking why you
needed to know. You could have just as easily made a bad assumption
about something else and were trying to fix it in the drag.
And if you would like to
On Mar 26, 2010, at 7:00 AM, Jeffrey J. Early wrote:
> When a user drags a photo from iPhoto to my application I need to be able to
> update iPhoto's database (via ScriptingBridge) with changes that are made
> while in my program.
Can you check the path to the file and see if it’s inside the i
I apparently didn't hit reply-all on my response to Steve.
I wrote:
When a user drags a photo from iPhoto to my application I need to be able to
update iPhoto's database (via ScriptingBridge) with changes that are made while
in my program. Other programs require different bits of "extra work" to
A fragile way would be to see what other drag types are being put on the
pasteboard. I imagine Finder has some esoteric old types for backwards
compatibility and I would guess that Aperture has some image types that the
Finder wouldn't normally use (except maybe for picture clippings)
But as St
I'm curious why you need to know where the drag originated since it
generally shouldn't matter. Do you have to do some extra work in one
case? And what happens if you see a drag from another application?
On Mar 25, 2010, at 7:55 AM, Jeffrey J. Early wrote:
Is there any way to determine the
Is there any way to determine the source of a drag operation outside your own
application? For example, if I'm set to receive NSFilenamesPboardType, then I'd
like to distinguish between the Finder and Aperture as drag sources.
I had thought I'd seen a solution to this at one point, but can't see
12 matches
Mail list logo
