Python programs (or scripts) as drop targets

[Alex Martelli]

"Mark Hammond" <MarkH at ActiveState.com> wrote in message
news:3A2ACF21.4060406 at ActiveState.com...
> Alex Martelli wrote:
>
> > I think IDropTarget must be implemented somewhere in Mark's code,
> > since *running* Python programs with win32all can be drop-targets.
> > (Dunno about IPersistXXX, but that shouldn't be a big problem).  But
> > that doesn't necessarily help with implementing what you desire, i.e.,
> > making a *shortcut* into a droptarget.
>
> Actually, the other way of getting it for a running program is Windows
> messages, and this is how win32all generally does it.  Indeed, win32gui

For a program that's *already* running, yes, there are several
ways it can handle having stuff being dropped on it (though I
think the COM solution is richer and more general).

> could knock this up OK.  It doesnt handle the "shell extensions"
> features Dale pointed at, where a new object is instantiated to handle
> the drop.

Right -- you do need COM for that.


> > But how this works for a _shortcut_ doesn't seem to be documented
> > at all.
>
> I understand the shortcut is simply resolved using the other shell APIs
> first.

So one loses the precious information that the shortcut has in
addition to the program-to-be-run, such as the flags, current
directory, etc?  Seems a suboptimal architecture to me (not that
this would be the first suboptimal architecture in the Win32 API
and surrounding subsystems, of course:-).


> > One thing we could do is invent a "new filetype" to be used *instead*
> ...
>
> To be quite honest, while I see that the "batch file" wrapper solution
> isnt as "clean" as it could be, I don't believe a whole bunch of C++
> code or registry additions are worth saving this one trivial file.

If saving a trivial file is indeed the only advantage of implementing
the shell extension, then you may be right (though quibbling about the
"registry additions" needed to _register_ a shell extension seems pretty
peculiar to me).


Alex