Python programs (or scripts) as drop targets 
Author Message
 Python programs (or scripts) as drop targets

I asked about this earlier but after a bit more research, have uncovered the following:

http://www.*-*-*.com/

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.

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.

--
Dale Strickland-Clark
Out-Think Ltd
Business Technology Consultants



Thu, 22 May 2003 03:00:00 GMT  
 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



Thu, 22 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

> 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.

Shortcuts behave like the referenced file so no problem there.

All I think we need is a small DLL that launches the Python program in a new process passing it an
arg list of all the files dropped on the icon.

There may already be a DLL shipped with Python with half the COM infrastructure already in place.
--
Dale Strickland-Clark
Out-Think Ltd
Business Technology Consultants



Thu, 22 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

> The big question now is: is such an interface exposed anywhere by Python?

A quick look shows we need IDropTarget and IDataObject.

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.

Sadly I don't have the time.  These interfaces would be added to the
existing "win32com.shell" module, so it wouldn't be as hard as creating
a new module.

I would probably use "win32com.makegw" to generate .cpp code.

Mark.



Thu, 22 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

> 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
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.

Quote:
> 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.

Quote:
> 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.

Mark.



Thu, 22 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets
Quote:
> So is there anyone out there with the VC++ skills sufficiently interested

in this idea to code the

Quote:
> necessary interfaces?

If there isn't support for doing this in python I could look into it. I've
made a couple of shell extensions before that sounds pretty similar so it
shouldn't be too much work.

Can't you contact me Dale if we can't find a way to do this in Python?



Thu, 22 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

> > 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).

Quote:
> 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.

Quote:
> > 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:-).

Quote:
> > 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



Fri, 23 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

> > The big question now is: is such an interface exposed anywhere by
Python?

> A quick look shows we need IDropTarget and IDataObject.

Why IDataObject?  I think IPersistFile is what's needed here.

Alex



Fri, 23 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

>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.

>Mark.

Yes, it is only a trivial file but it's the messing about to set it up and you need one for each
program you want to work this way.

It's not just a matter of neatness. It's completeness, too.

--
Dale Strickland-Clark
Out-Think Ltd
Business Technology Consultants



Fri, 23 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

>> So is there anyone out there with the VC++ skills sufficiently interested
>in this idea to code the
>> necessary interfaces?

>If there isn't support for doing this in python I could look into it. I've
>made a couple of shell extensions before that sounds pretty similar so it
>shouldn't be too much work.

>Can't you contact me Dale if we can't find a way to do this in Python?

As far as I can tell, this isn't a big job but I think it would be neater if it was built into the
standard Python distribution.

Mark has suggested  that it could go in win32com.shell - although I can't figure out what he means
by that - win32comext.shell, perhaps?

Is the source for this available?

--
Dale Strickland-Clark
Out-Think Ltd
Business Technology Consultants



Fri, 23 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

> 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).

Hrm - I hope you didn't think I was quibbling about that!  You won't
find me arguing against that.  I apologize if that is what I was saying!

While we are at it, the registry information needed to the shell
communicates to a running Pythonwin via DDE (instead of a new Pythonwin
startng and _it_ using DDE) would be nice too ;-)

Mark.



Sat, 24 May 2003 12:54:51 GMT  
 Python programs (or scripts) as drop targets

Quote:

> Mark has suggested  that it could go in win32com.shell - although I can't figure out what he means
> by that - win32comext.shell, perhaps?

Yes - it is imported as "win32com.shell", but exists in a different tree
as it is not part of the "COM core".  Such a distinction is a little
pointless...

Quote:
> Is the source for this available?

With the rest of the sources.  See my win32all pages.

Mark.



Sat, 24 May 2003 13:18:44 GMT  
 Python programs (or scripts) as drop targets

Quote:


>> Mark has suggested  that it could go in win32com.shell - although I can't figure out what he means
>> by that - win32comext.shell, perhaps?

>Yes - it is imported as "win32com.shell", but exists in a different tree
>as it is not part of the "COM core".  Such a distinction is a little
>pointless...

>> Is the source for this available?

>With the rest of the sources.  See my win32all pages.

>Mark.

Thanks.
--
Dale Strickland-Clark
Out-Think Ltd
Business Technology Consultants


Sat, 24 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets

Quote:

> > 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).

> Hrm - I hope you didn't think I was quibbling about that!  You won't
> find me arguing against that.  I apologize if that is what I was saying!

> While we are at it, the registry information needed to the shell
> communicates to a running Pythonwin via DDE (instead of a new Pythonwin
> startng and _it_ using DDE) would be nice too ;-)

<shudder> if we're talking DDE, there is *another* issue which I
find more pressing: DDEML is *NOT* usable in professional apps
(although many apps that call themselves professional do use it).

Reason: DDEML's functions (those which need to broadcast) use
SendMessage, WITHOUT a timeout!, to broadcast their messages.  So,
DDEML-using applications tend to hang if anybody, anywhere on the
system, has a top-level window whose messages it isn't serving.
And this happens very often (hung processes, etc, etc).  It's a
shame to let ANY other buggy app on the system hang yours...!

DDE itself is a very bad protocol, but the hang problem is quite
specifically with the DDEML helper library -- it's a bug which
MS has acknowledged (5 years ago, I think) yet will never be
fixed (MS apparently does NOT want to encourage DDE use in any
way, shape, or form).  The only fix I can think of is to
rearchitect code that needs to use DDE in order to have it
use the low-level DDE messages (AND SendMessageTimeout any
time it needs to broadcast...!) instead of DDEML.  Better would
be to root out any DDE use whatsoever, of course (relying instead
totally on the COM interfaces to the shell -- best documented
in Dino Esposito's book published by Wrox Press).

Alex



Sat, 24 May 2003 03:00:00 GMT  
 Python programs (or scripts) as drop targets
Alex Martelli:

Quote:
> <shudder> if we're talking DDE, there is *another* issue which I
> find more pressing: DDEML is *NOT* usable in professional apps
> (although many apps that call themselves professional do use it).

   Agree completely here - various versions of DDEML have also had some
rather {*filter*} race conditions. I once wrote an application based upon DDEML
only to stumble across these problems. There is the additional burden when
using DDEML of really needing to understand the underlying DDE protocol at
the same time as DDEML's 'simplified' version at the same time to debug. Its
more trouble than just learning DDE.

   Later, a colleague who was familiar with the history of DDEML within MS
said that it was an orphaned project and no one wanted to maintain it.

   Neil



Sat, 24 May 2003 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Python scripts as Drop targets in Windows Explorer

2. Python as a drop target (win32)

3. VX-REXX: Getting info. on WPS Drop Target

4. blt_drag&drop target remove ?

5. Script in Python to run a C program

6. Calling Python scripts from C/C++ program

7. Using Python as a scripting language in a Borland Delphi program

8. Calling a python program within a python program

9. Python 2.1 distutils swig_cpp and binary installation target dir question

10. building python for multiple targets

11. asharedmodule target of Python-1.5/Modules/Makefile missing in 1.5.1

12. Python's bininstall target is wrong in a multi-version environment

 

 
Powered by phpBB® Forum Software