HELP! win32com, COM, Invoke problem

[Alex Martelli]

"TB" <tblin at my-deja.com> wrote in message
news:92u2u4$2vi$1 at nnrp1.deja.com...
>
>
> > You may have trouble with an OCX.  Python doesn't really support them.
> > Pythonwin does to some degree - check out pywin\demos\ocx.
>
> Well, it sounds like a naive question but what does it take to have
> python support OCX? the reason here is that if it doesn't provide a
> drop-in replace VBScript/JScript, it's hard to have the management's
> (sorry, you know that)  buy-in on using it. Plus, it's nice to have this
> feature anyway.

Being a "proper and complete Active/X Control Container" is a daunting
task indeed -- Active/X Controls (aka OCX's) can choose to implement,
totally or partially, each of a zillion interfaces, and the 'host' (the
'control container') is supposed to adjust to each and every variation.

The Microsoft System Journal, issue of 12/99, has a nice article on
(some of) what it takes to do that for ATL -- have a look at (one line!):
http://www.microsoft.com/msj/defaulttop.asp?page=/msj/1299/containment/conta
inmenttop.htm
if you read enough C++ to follow it -- you can also download the
VBlite.zip sources for the "full-blown control container" that
Dharma Shukla and Chris Sells develop in the article (but it doesn't
really address *all* possible issues).

VBScript and JScript don't even TRY to "be control containers" -- it
would be silly for either of them to do so: in Microsoft's architecture,
their role is well-defined as "Active/X Scripting Language" engines.
Control containment is not the job of a language, but of the framework
or application that embeds the language.  The language's role is to
let one *script* controls that are hosted on the "forms" (or however
you want to call them) of the application -- receive events, set and
get properties, call methods.

The best reusable and redistributable control-container for most uses
is (IMHO) Internet Explorer.  If you need the controls to be visually
part of some other existing window/form/dialog/whatever, it's far
simpler to have the 'whatever' support just the bare minimum needed to
host the IE subset you need, and ember the generic OCX's into the IE
subset.  IE's *very* well-behaved, far easier to host properly than
most other OCX's you'll find around -- and also hosts Active Documents
(another dauntint task to reimplement), Java applets, whatever.  It's
truly a fully general, reusable framework, rich, easy to use, well
documented.

If for some political reason you cannot require "a reasonably updated
IE version" as a part of your applications' prereq's, your life is
much harder (but would be absolutely NO easier if your preferred
language was VBScript or JScript!!!).  "VBLite" can be seen as an
option in that case (I'm not sure about the legal status of it as
a redistributable binary, though -- do check if you plan on that!).

MFC dialogs, VB forms, MS Office products, and, I assume, some of
their competitors' equivalents (Delphi, StarOffice, Mozilla, Opera,
...?), all may provide other suitable replacements depending on your
deployment strategies.  Pythonwin (somewhat based on MFC, if I recall
correctly) and wxWindows may also fit in this array of choices.  But,
really, if you can standardize on the array of technologies that are
"already deployed for you" by any recent IE release, your life WILL
be a lot simpler.


> I tried to read something about COM and etc, but the info I'm getting is
> just overwhelmingly complex. could you shed some light on how does VB
> use OCX? and why it's different from other things (that win32com that
> currently support) ?

VB Forms may be the second-best Active/X Control Containers Microsoft
makes, right after Internet Explorer.  In these cases, sources are not
distributed, so finding out in detail how they work needs a lot of
reverse engineering (in jurisdictions where reverse engineering is
legal, of course; you just can't do it elsewhere).  "VBLite" (and all
of ATL that it rests on) and MFC _are_ distributed with sources, so
in these cases finding out all of the excruciating details just takes
a lot of patience and competence with C++, VStudio's debugger, etc.

But anyway, summarizing: win32com does not implement 'forms' that one
could use as (even a start of) proper "Active/X Control Containers";
it's just not its job to duplicate this kind of functionality.  It
is, in some part, done in Pythonwin (which IS a framework for general
development of Windows GUI's), etc.


> Any plan to support OCX in win32com in the future? I'd like to help but
> I guess I have a lot to learn even before I can make sense of what
> you've done. Any suggest reading to begin with? I'm more of a
> unix/perl/java guy and do some VB but never went seriously into C++ on
> Windows.

As long as the functionality is there, easily accessible, why would
one desire that it be duplicated among several disparate packages --
why should win32com implement the general-purpose GUI portions needed
to properly host any and all Active/X controls?

> Do you think it makes sense to manually write some wrappers to solve
> this immediate problem? any idea how to do that (w/o going into C++ and
> pyd) ?

Instantiate whatever part you need of Internet Explorer -- that gives
you all you could ever possibly need.  If you need fine-grained control
of user-interface's look-and-feel, you can host MSHTML in diverse ways;
MSDN has a _lot_ of information on that, although it's generally
expressed in terms of VB or C++ use.  But for most programming tasks,
http://msdn.microsoft.com/workshop/author/hta/overview/htaoverview.asp
(the "HTML Applications" concept) are, for example, one great deployment
possibility -- check out http://www.webreference.com/js/column39/, which
gives a good, thorough tutorial introduction, albeit centered on using
JScript as the specific scripting language (but by installing win32all,
Python becomes usable in any active-scripting scenario where JScript
might be considered).


Alex