[python-win32] RE: Can we add 'native COM support' to a 3rd party DLL/OLB

[Craig Taverner]

> :-(  I had inferred that Pythoncom's early binding would be sufficient
> to deal with the documented IDispatch restriction, but Bill's comments
> would seem to make that unlikely...
> 
> I came across 1 reference to vtables (C++) based interfaces in the
> Pythoncom help file, albeit in relation to COM servers, which gives
> me faint hope this is still feasible.  Lots of reading & code
inspection
> still to do...

Let me know what you find. I also still have hope. I think the system
the ESRI developers worked on was generic to three languages. We're only
interested in one, and python is supposed to be easy to extend, so I
think a relatively simple solution must be possible.

> While comfortable with C, C++ is something I've never gotten into.  I
> was hoping I could use Python instead of VB for my Arc based app.

That is exactly my hope. Also we do a lot of java programming server
side and are using Jython for scripting in that, so we also want to keep
python for scripting in the ArcObjects based clients.

> > I've any of the pythonwin masters have an answer here, that would be
> > great!

I've changed the subject line to reflect the primary question to the
python-win32 list, in case they have an answer for us.

> I've been using Python and Arc/Info (the workstation version) for a
> few years, and have picked up some ArcObjects familiarity through
> MXD document macros in VBA, so my learning curve isn't quite as steep
> ...

I'm new to python, COM and ArcGIS, but experienced with threads, CORBA,
Java and some C++, so we're approaching this problem from different
directions. Can only help ;-)

> Sorry :-(  I have little experience with threading full stop.

My only strength ;-) (at least I'm experienced with posix threads,
omnithreads, java threads, and now trying out python and win32 threads).