Python programs (or scripts) as drop targets

[Alex Martelli]

"Mark Hammond" <MarkH at ActiveState.com> wrote in message
news:3A2C73CE.5060506 at ActiveState.com...
> Alex Martelli wrote:
>
> > 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