[wxpython-dev] ActiveX Poll

Robin Dunn wrote:
> Hi all, I've got some questions for you:
>
>
> Do you use one of the ActiveX solutions provided by wxPython?
>
> Which one? (wx.lib.activexwrapper or wx.activex)
>
> What ActiveX controls are you embedding?
>
> Are you using one of the existing wx.lib.iewin, wx.lib.pdfwin, or
> wx.lib.flashwin modules?
>

Also, which version(s) of Python are you doing this with?


--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

Paul McNett wrote:

>> [ Yes, you can read between the lines and conclude that I've got
>> something new up my sleeve... ;-) ]
>
> Do tell!

It's an almost pure Python implementation using ctypes and comtypes
(http://starship.python.net/crew/theller/comtypes/) and provides the
strengths of both of the current solutions without the weaknesses:

* Full dynamic dispatch like PyWin32/activexwrapper and unlike
wx.activex. This means that you can access and use any of the
properties or methods of the AX objects (such as the Document property
in the IE control) no matter what type or interface they are, instead of
only those where there's support in the C++ wrapper.

* Python classes are generated on demand as the COM interfaces are
needed, (if there is a typelib available) so a lot of the hard work of
doing fully dynamic dispatch is only done once, not each time you use
it. If desired there is an easy way to ensure that this generation
takes place during development and that the needed modules are included
in py2exe style bundles so your users don't have to go through that
class generation step.

* Unlike PyWin32 this is very light-weight. The comtypes package is
pure Python and not very big. Using it and ctypes I'm able to do in
about 100 lines of Python code what took thousands of lines of C++ code
for wx.activex and who knows how much for PyWin32. Of course once you
add the generated code for the COM classes then that line count goes up
quite a bit, but that doesn't need to be maintained or even understood,
so it doesn't count. ;-)

* I'm using the native AtlAxWin window type as the container, so IIUC
this means that some things that bothered us in the past because of not
providing all the interfaces needed for some ActiveX controls should be
non-existant. For example the problems that we had with Acrobat Reader
7 that required us to change pdfwin.py to actually embed it in a IE
object instead of doing it directly. I haven't tried Acrobat 7 yet, but
version 8 loaded with absolutely no problems at all.

* Like wx.activex and unlike PyWin32 the container is a real wx.Window
so most things you can do with a wx.Window should work fine, although
the actual ActiveX control will end up being a child of the AtlAxWin so
you won't be able to do things like intercept its low level events and
what-not, but you can always use the COM interfaces and/or ctypes to do
it in a native way. I mentioned above that it is an almost pure Python
implementation. By this I meant that I had to add a new wxWindow class
that exposes one of the internal wxMSW virtual methods and allows it to
be overridden in Python, and this is used as the base class of the new
ActiveX class. If that change hadn't been required then this code would
probably be usable with current releases of wxPython.


The only downside so far is that it may not be worth the effort to use
this in a clean replacement of iewin.py, pdfwin.py and flashwin.py
because the events are handled differently. I haven't given up on that
yet though.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

Please dear god do it! From your description, it looks like this will
give wxPython the same ease in deploying COM/ActiveX controls that
VisualBasic has.

That can only be a good thing.

Chris.

On Fri, 06 Jun 2008 16:31:38 -0700, Robin Dunn <[email protected]>
wrote:

>Paul McNett wrote:
>
>>> [ Yes, you can read between the lines and conclude that I've got
>>> something new up my sleeve... ;-) ]
>>
>> Do tell!
>
>It's an almost pure Python implementation using ctypes and comtypes
>(http://starship.python.net/crew/theller/comtypes/) and provides the
>strengths of both of the current solutions without the weaknesses:
>
>* Full dynamic dispatch like PyWin32/activexwrapper and unlike
>wx.activex. This means that you can access and use any of the
>properties or methods of the AX objects (such as the Document property
>in the IE control) no matter what type or interface they are, instead of
>only those where there's support in the C++ wrapper.
>
>* Python classes are generated on demand as the COM interfaces are
>needed, (if there is a typelib available) so a lot of the hard work of
>doing fully dynamic dispatch is only done once, not each time you use
>it. If desired there is an easy way to ensure that this generation
>takes place during development and that the needed modules are included
>in py2exe style bundles so your users don't have to go through that
>class generation step.
>
>* Unlike PyWin32 this is very light-weight. The comtypes package is
>pure Python and not very big. Using it and ctypes I'm able to do in
>about 100 lines of Python code what took thousands of lines of C++ code
>for wx.activex and who knows how much for PyWin32. Of course once you
>add the generated code for the COM classes then that line count goes up
>quite a bit, but that doesn't need to be maintained or even understood,
>so it doesn't count. ;-)
>
>* I'm using the native AtlAxWin window type as the container, so IIUC
>this means that some things that bothered us in the past because of not
>providing all the interfaces needed for some ActiveX controls should be
>non-existant. For example the problems that we had with Acrobat Reader
>7 that required us to change pdfwin.py to actually embed it in a IE
>object instead of doing it directly. I haven't tried Acrobat 7 yet, but
>version 8 loaded with absolutely no problems at all.
>
>* Like wx.activex and unlike PyWin32 the container is a real wx.Window
>so most things you can do with a wx.Window should work fine, although
>the actual ActiveX control will end up being a child of the AtlAxWin so
>you won't be able to do things like intercept its low level events and
>what-not, but you can always use the COM interfaces and/or ctypes to do
>it in a native way. I mentioned above that it is an almost pure Python
>implementation. By this I meant that I had to add a new wxWindow class
>that exposes one of the internal wxMSW virtual methods and allows it to
>be overridden in Python, and this is used as the base class of the new
>ActiveX class. If that change hadn't been required then this code would
>probably be usable with current releases of wxPython.
>
>
>The only downside so far is that it may not be worth the effort to use
>this in a clean replacement of iewin.py, pdfwin.py and flashwin.py
>because the events are handled differently. I haven't given up on that
>yet though.
_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

I try to avoid any platform-specific options that don't have a compatible
re-implementation on other platforms and specifically avoid Active-X
whenever possible so it's unlikely I'd ever utilize the components you're
talking about. That said I find your solution interesting and wonder if it
wouldn't be applicable to connecting with other COM-interfaced systems under
Windows. Forgive my ignorance but why is this only useful for or
particularly focused on Active-X stuff?

-- Ben

PS: Regardless - this is not a vote against. I think anything that helps get
python embedded in more platforms and displace VB or C# is a good thing.

On Sat, Jun 7, 2008 at 6:31 AM, Robin Dunn <[email protected]> wrote:

> Paul McNett wrote:
>
> [ Yes, you can read between the lines and conclude that I've got something
>>> new up my sleeve... ;-) ]
>>>
>>
>> Do tell!
>>
>
> It's an almost pure Python implementation using ctypes and comtypes (
> http://starship.python.net/crew/theller/comtypes/) and provides the
> strengths of both of the current solutions without the weaknesses:
>
> * Full dynamic dispatch like PyWin32/activexwrapper and unlike wx.activex.
> This means that you can access and use any of the properties or methods of
> the AX objects (such as the Document property in the IE control) no matter
> what type or interface they are, instead of only those where there's support
> in the C++ wrapper.
>
> * Python classes are generated on demand as the COM interfaces are needed,
> (if there is a typelib available) so a lot of the hard work of doing fully
> dynamic dispatch is only done once, not each time you use it. If desired
> there is an easy way to ensure that this generation takes place during
> development and that the needed modules are included in py2exe style bundles
> so your users don't have to go through that class generation step.
>
> * Unlike PyWin32 this is very light-weight. The comtypes package is pure
> Python and not very big. Using it and ctypes I'm able to do in about 100
> lines of Python code what took thousands of lines of C++ code for wx.activex
> and who knows how much for PyWin32. Of course once you add the generated
> code for the COM classes then that line count goes up quite a bit, but that
> doesn't need to be maintained or even understood, so it doesn't count. ;-)
>
> * I'm using the native AtlAxWin window type as the container, so IIUC this
> means that some things that bothered us in the past because of not providing
> all the interfaces needed for some ActiveX controls should be non-existant.
> For example the problems that we had with Acrobat Reader 7 that required us
> to change pdfwin.py to actually embed it in a IE object instead of doing it
> directly. I haven't tried Acrobat 7 yet, but version 8 loaded with
> absolutely no problems at all.
>
> * Like wx.activex and unlike PyWin32 the container is a real wx.Window so
> most things you can do with a wx.Window should work fine, although the
> actual ActiveX control will end up being a child of the AtlAxWin so you
> won't be able to do things like intercept its low level events and what-not,
> but you can always use the COM interfaces and/or ctypes to do it in a native
> way. I mentioned above that it is an almost pure Python implementation. By
> this I meant that I had to add a new wxWindow class that exposes one of the
> internal wxMSW virtual methods and allows it to be overridden in Python, and
> this is used as the base class of the new ActiveX class. If that change
> hadn't been required then this code would probably be usable with current
> releases of wxPython.
>
>
> The only downside so far is that it may not be worth the effort to use this
> in a clean replacement of iewin.py, pdfwin.py and flashwin.py because the
> events are handled differently. I haven't given up on that yet though.
>
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org Java give you jitters? Relax with wxPython!
>
> _______________________________________________
> wxpython-dev mailing list
> [email protected]
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev
>
I try to avoid any platform-specific options that don&#39;t have a compatible re-implementation on other platforms and specifically avoid Active-X whenever possible so it&#39;s unlikely I&#39;d ever utilize the components you&#39;re talking about. That said I find your solution interesting and wonder if it wouldn&#39;t be applicable to connecting with other COM-interfaced systems under Windows. Forgive my ignorance but why is this only useful for or particularly focused on Active-X stuff?<br>
<br>&nbsp; -- Ben<br><br>PS: Regardless - this is not a vote against. I think anything that helps get python embedded in more platforms and displace VB or C# is a good thing.<br><br><div class="gmail_quote">On Sat, Jun 7, 2008 at 6:31 AM, Robin Dunn &lt;<a href="mailto:robin@alldunn.com">robin@alldunn.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Paul McNett wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

[ Yes, you can read between the lines and conclude that I&#39;ve got something new up my sleeve... &nbsp;;-) ]<br>
</blockquote>
<br>
Do tell!<br>
</blockquote>
<br></div>
It&#39;s an almost pure Python implementation using ctypes and comtypes (<a href="http://starship.python.net/crew/theller/comtypes/" target="_blank">http://starship.python.net/crew/theller/comtypes/</a>) and provides the strengths of both of the current solutions without the weaknesses:<br>

<br>
* Full dynamic dispatch like PyWin32/activexwrapper &nbsp;and unlike wx.activex. &nbsp;This means that you can access and use any of the properties or methods of the AX objects (such as the Document property in the IE control) no matter what type or interface they are, instead of only those where there&#39;s support in the C++ wrapper.<br>

<br>
* Python classes are generated on demand as the COM interfaces are needed, (if there is a typelib available) so a lot of the hard work of doing fully dynamic dispatch is only done once, not each time you use it. &nbsp;If desired there is an easy way to ensure that this generation takes place during development and that the needed modules are included in py2exe style bundles so your users don&#39;t have to go through that class generation step.<br>

<br>
* Unlike PyWin32 this is very light-weight. &nbsp;The comtypes package is pure Python and not very big. &nbsp;Using it and ctypes I&#39;m able to do in about 100 lines of Python code what took thousands of lines of C++ code for wx.activex and who knows how much for PyWin32. &nbsp;Of course once you add the generated code for the COM classes then that line count goes up quite a bit, but that doesn&#39;t need to be maintained or even understood, so it doesn&#39;t count. &nbsp;;-)<br>

<br>
* I&#39;m using the native AtlAxWin window type as the container, so IIUC this means that some things that bothered us in the past because of not providing all the interfaces needed for some ActiveX controls should be non-existant. &nbsp;For example the problems that we had with Acrobat Reader 7 that required us to change pdfwin.py to actually embed it in a IE object instead of doing it directly. &nbsp;I haven&#39;t tried Acrobat 7 yet, but version 8 loaded with absolutely no problems at all.<br>

<br>
* Like wx.activex and unlike PyWin32 the container is a real wx.Window so most things you can do with a wx.Window should work fine, although the actual ActiveX control will end up being a child of the AtlAxWin so you won&#39;t be able to do things like intercept its low level events and what-not, but you can always use the COM interfaces and/or ctypes to do it in a native way. &nbsp;I mentioned above that it is an almost pure Python implementation. &nbsp;By this I meant that I had to add a new wxWindow class that exposes one of the internal wxMSW virtual methods and allows it to be overridden in Python, and this is used as the base class of the new ActiveX class. &nbsp;If that change hadn&#39;t been required then this code would probably be usable with current releases of wxPython.<br>

<br>
<br>
The only downside so far is that it may not be worth the effort to use this in a clean replacement of iewin.py, pdfwin.py and flashwin.py because the events are handled differently. &nbsp;I haven&#39;t given up on that yet though.<div class="Ih2E3d">
<br>
<br>
-- <br>
Robin Dunn<br>
Software Craftsman<br>
<a href="http://wxPython.org" target="_blank">http://wxPython.org</a> &nbsp;Java give you jitters? &nbsp;Relax with wxPython!<br>
<br>
_______________________________________________<br></div><div><div></div><div class="Wj3C7c">
wxpython-dev mailing list<br>
<a href="mailto:wxpython-dev@lists.wxwidgets.org" target="_blank">wxpython-dev@lists.wxwidgets.org</a><br>
<a href="http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev" target="_blank">http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev</a><br>
</div></div></blockquote></div><br>
_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev