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?
[ Yes, you can read between the lines and conclude that I've got something new up my sleeve... 
]
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Hi all, I've got some questions for you:
Do you use one of the ActiveX solutions provided by wxPython?
Begrudgingly, yes.
Which one? (wx.lib.activexwrapper or wx.activex)
What ActiveX controls are you embedding?
No custom ActiveX (I don't use either of the above directly).
Are you using one of the existing wx.lib.iewin, wx.lib.pdfwin, or wx.lib.flashwin modules?
wx.lib.pdfwin, although I keep turning it off because of too many problems with different IE and Adobe Acrobat Reader versions.
[ Yes, you can read between the lines and conclude that I've got something new up my sleeve...
]
Do tell!
Paul
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!
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!
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?
I'm using wx.lib.iewin in one of my projects with Python 2.5.
--
Best Regards,
Alexei Vinidiktov
I am using wx.lib.pdfwin with Python-2.5 and wxPython-2.8.7.1
and I willing to give up compatibility with the old
implementation in exchange for better control.
Waldemar
On Fri, Jun 6, 2008 at 3:48 PM, Robin Dunn <robin@alldunn.com> 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?
Are you using one of the existing wx.lib.iewin, wx.lib.pdfwin, or
wx.lib.flashwin modules?
No.
- Even if I'm working on Windows, I tend to write platform independent
applications, al least in spirit.
- I'm using FireFox.
- In my experience, these widgets bring to many troubles. Not only on the
Python/wxPython side, but on the side of the applications they are supposed
to use. (Eg I'm using Acrobat Reader 5.0, small and fast).
- I just wonder if ctypes has not open the Pandora's box.
Jean-Michel Fauth, Switzerland
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 <robin@alldunn.com> 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.
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 robin@alldunn.com 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
Benjamin Scherrey wrote:
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?
The comtypes module can handle just about anything COM related. Allowing ActiveX controls to be used in a wxPython app is what needed a bit more work.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!