Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix the crash-on-ActiveX-callback problem

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@16054 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
2002-07-06 00:55:46 +00:00
parent bd5dfc0725
commit 763d71e442
2 changed files with 16 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
wxPython/CHANGES.txt
View File

@@ -142,6 +142,13 @@ ActiveXWrapper already in the library, but it is implemented all in
C++ and therefore does not need any of the modules from win32 all and C++ and therefore does not need any of the modules from win32 all and
so it is less fragile in the face of changes. so it is less fragile in the face of changes.
Fixed the ActiveXWrapper problem. Looks like when the win32com
modules make a "callback" that they (incorrectly, IMHO) allocate a
transient thread state structure. Since wxPython is now saving
tstates for it's own callbacks it ended up using garbage after
win32com gots rid of the tstate...
2.3.2.1 2.3.2.1

10
wxPython/src/helpers.cpp
View File

@@ -586,7 +586,15 @@ void wxPySaveThreadState(PyThreadState* tstate) {
for(size_t i=0; i < wxPyTStates->GetCount(); i++) { for(size_t i=0; i < wxPyTStates->GetCount(); i++) {
wxPyThreadState& info = wxPyTStates->Item(i); wxPyThreadState& info = wxPyTStates->Item(i);
if (info.tid == ctid) { if (info.tid == ctid) {
info.tstate = tstate; #if 0
if (info.tstate != tstate)
wxLogMessage("*** tstate mismatch!???");
#endif
// info.tstate = tstate; *** DO NOT updating existing ones???
// Normally it will never change, but apparently COM callbacks
// (i.e. ActiveX controls) will (incorrectly IMHO) use a transient
// tstate wich will then be garbage the next time we try to use
// it...
wxPyTMutex->Unlock(); wxPyTMutex->Unlock();
return; return;
} }