Python programs (or scripts) as drop targets
Quote:
> I asked about this earlier but after a bit more research, have uncovered
the following:
http://msdn.microsoft.com/library/psdk/shellcc/shell/Shell_Int/DropHa....
htm
Quote:
> Which explains how it is implimented.
> The big question now is: is such an interface exposed anywhere by Python?
> However, I assume that, if it was, Mark would have known about it and
> mentioned it in his earlier reply.
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.
I'm not sure about the details, but I assume that what happens when
files are dropped on a *file* with a droptarget-registered *file extension*
is that: the COM class registered as its drop-handler is instantiated (the
MS docs say it must be an in-process server, so it must be a DLL; I guess
it's instantiated in the Explorer [shell] process), its IPersistFile
interface
queried, and through its Load method the file on which the drop is done
gets passed to it; then IDropTarget is queried for and the files being
dragged-and-dropped are passes through that one.
But how this works for a _shortcut_ doesn't seem to be documented
at all.
One thing we could do is invent a "new filetype" to be used *instead*
of a shortcut. It could have textual content that IS a script or maybe
better POINTS to a script, and a unique extension, on which various
handlers could be defined (drop, no doubt, but maybe also others).
One decision to be made: in which process should it run the Python
code -- i.e., should it use a python.exe or pythonw.exe (or something
else) to run in a separate process, or run the Python code right
within the (shell?) process. The latter seems faster but riskier.
Basically, if the contents of the new filetype *point* to a script, and
execution is in another process, then we'd be reinventing (a subset
of) .BAT's abilities (a .BAT with a line of python.exe foo.py %1 %2 etc
would be basically similar).
It's also possible (one should check...) that Windows Scripting Host
also does that (what happens if one drags-and-drops files to a .pys
or .wsf or...?) -- in which case the pointing-to-script vs containing
code directly would go away (a .wsh can do either -- it's an XML file
and can hold in a structured way both inline code and 'src=filepath'
refeences to other code files, in one or more scripting languages).
This would just leave the issue that WSH runs in a separate process
(normally, at least) while in theory a custom implementation could
try to squeeze out a micron of performance (at some serious risk to
system stability) by trying to run in the shell process itself instead.
It's an open question whether a _shortcut_ to a file of the given
type would be a drop-target just like the file itself. But some
experimentation could solve that.
A custom implementation might perhaps be used directly on
existing extensions (.py, .pyw, .pys, .pyo, .pyc, ...) rather than
a new extension. Interoperability with shortcuts still unknown.
Quote:
> So is there anyone out there with the VC++ skills sufficiently interested
in this
> idea to code the necessary interfaces?
> Sadly, I don't have the skills.
I can and do frequently code COM servers with VC++ and ATL. Often,
I've found that the easiest way to let scripting languages work 'almost
seamlessly' with non-Automation interfaces (implementing and/or
consuming them) is to write a thin delegation layer in VC++/ATL,
as an Automation object, which "implements" a custom interface by
delegating to a scripting-object it holds (I've found ScriptControl to
be quite serviceable for that), or (simpler) brokers a script's calls to
a custom interface.
But in this case it seems something different may be required.
I'm unsure about the actual usefulness of this... if WSH allows it
(albeit only on .pys and/or .wsf), the added value of a custom DLL
would appear to be pretty low. Still, the amount of effort might not
be too bad.
Alex