It seems from our testing that there are two different issues with ActiveX
controls.
1) The IE demo crash - appearing to be related to the thread state 2.3.2.1
changes. It worked in our builds of 2.3.2bX
2) Any MFC developed OCX used in or after 2.3.2b6 will cause a crash (at least)
when opening a new frame window.
For whatever reason once an MFC based MSVC activex control has been
instantiated, any following wxFrame creation will cause a stack overflow.
This overflow is due to the HWND created by CreateWindowEx (in
wxWindowMSW::MSWCreate ) having a default WndProc of _AfxActivationWndProc from
WinCore.cpp. Once the SubClassWin function is called the m_oldWndProc variable
is set to _AfxActivationWndProc and the wxWndProc set as the new default. Once
the next statement of SetFont gets called an infinite recursion happens with
wxWndProc calling AfxActivationWndProc which calls wxWndProc back.
In versions before 2.3.2b6 this same redefinition of the default window handler
was occurring but the SubClassWindow was being called differently so that this
behavior was not an apparent issue.
I don't understand why the MFC controls are changing an ensuing wxFrame
creation, while a VB based control or non-MFC MSVC control won't. Would it be
an MFC issue or win32all or wxWindows or wxPython.
To test this I built a default MFC activex control in VC and replaced the IE
browser in the wxPython\demo\demo.py. I then overloaded the 'home' button to
open a new frame: wxFrame(None, -1, "test crash").Show(1)
Anyone seen this problem or have an idea?
Thanks,
Barry
Win2k sp2, VC6 sp5, ActivePython 2.2, win32all 146, wxWindows from the CVS -
built/tested 2.3.1, 2.3.2 betas 5,6,7, 2.3.2 and HEAD