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

typos

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@16056 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
2002-07-06 01:10:38 +00:00
parent c2dac7366c
commit 46e10fde20
2 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
wxPython/CHANGES.txt
View File

@@ -146,7 +146,7 @@ Fixed the ActiveXWrapper problem. Looks like when the win32com
modules make a "callback" that they (incorrectly, IMHO) allocate a modules make a "callback" that they (incorrectly, IMHO) allocate a
transient thread state structure. Since wxPython is now saving transient thread state structure. Since wxPython is now saving
tstates for it's own callbacks it ended up using garbage after tstates for it's own callbacks it ended up using garbage after
win32com gots rid of the tstate... win32com got rid of the tstate...

4
wxPython/src/helpers.cpp
View File

@@ -590,10 +590,10 @@ void wxPySaveThreadState(PyThreadState* tstate) {
if (info.tstate != tstate) if (info.tstate != tstate)
wxLogMessage("*** tstate mismatch!???"); wxLogMessage("*** tstate mismatch!???");
#endif #endif
// info.tstate = tstate; *** DO NOT updating existing ones??? // info.tstate = tstate; *** DO NOT update existing ones???
// Normally it will never change, but apparently COM callbacks // Normally it will never change, but apparently COM callbacks
// (i.e. ActiveX controls) will (incorrectly IMHO) use a transient // (i.e. ActiveX controls) will (incorrectly IMHO) use a transient
// tstate wich will then be garbage the next time we try to use // tstate which will then be garbage the next time we try to use
// it... // it...
wxPyTMutex->Unlock(); wxPyTMutex->Unlock();
return; return;