Hi everyone,
the situation with wx.ActiveX in wxPython seems to be the following:
1. wxActiveX (from http://wxactivex.sf.net/) seems to have a serious bug at the moment, which causes it to prevent access to all properties in many controls. Some controls work, but all controls using the standard way to expose properties won't. E.g., all controls written using MFC (and probably ATL) do not work.
2. wxActiveX seems to be unmaintained at the moment. The bug in question has been known for over half a year, and there is even a patch available to fix the behaviour. Furthermore, I have tried to contact the maintainer (Lindsay Mathieson) days ago and did not get a response.
These problems shouldn't matter too much for C++ use of wx, because wxActiveX is an optional component, and must be built separately. So anyone wishing to use it will need to compile it anyway (and they have the compiler, since they do C++ development), and can apply patches.
In wxPython, wxActiveX is included by default, and according to the 2.6 "Migration Guide" it is ment to be the preferred way to access ActiveX controls. There are also many users for wxPython who don't have a C++ compiler and/or the skills to rebuild the wxActiveX extension module.
I therefore propose that a locally patched wxActiveX version is maintained inside the wxPython source tree. I volunteer to review the patch which is on the wxActiveX site and fix wxActiveX accordingly. The fixed wxActiveX control could then be included into the next wxPython version (2.6.1.1?).
Markus
Hello Markus:
I am one who would find it very helpful if your suggestion were carried
out. It has been so long since I used a C compiler that I usually just
give up if that is required. Thank you for your generous offer of time
and effort. I sincerely hope the keepers of the wxPython source tree
agree.
ยทยทยท
On 9/30/05, Markus Meyer <meyer@mesw.de> wrote:
Hi everyone,
the situation with wx.ActiveX in wxPython seems to be the following:
1. wxActiveX (from http://wxactivex.sf.net/) seems to have a serious bug
at the moment, which causes it to prevent access to all properties in
many controls. Some controls work, but all controls using the standard
way to expose properties won't. E.g., all controls written using MFC
(and probably ATL) do not work.
2. wxActiveX seems to be unmaintained at the moment. The bug in question
has been known for over half a year, and there is even a patch available
to fix the behaviour. Furthermore, I have tried to contact the
maintainer (Lindsay Mathieson) days ago and did not get a response.
These problems shouldn't matter too much for C++ use of wx, because
wxActiveX is an optional component, and must be built separately. So
anyone wishing to use it will need to compile it anyway (and they have
the compiler, since they do C++ development), and can apply patches.
In wxPython, wxActiveX is included by default, and according to the 2.6
"Migration Guide" it is ment to be the preferred way to access ActiveX
controls. There are also many users for wxPython who don't have a C++
compiler and/or the skills to rebuild the wxActiveX extension module.
I therefore propose that a locally patched wxActiveX version is
maintained inside the wxPython source tree. I volunteer to review the
patch which is on the wxActiveX site and fix wxActiveX accordingly. The
fixed wxActiveX control could then be included into the next wxPython
version (2.6.1.1?).
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org