Using wxTheApp when the corresponding object is already half destroyed can't
be a good idea so reset it to NULL as soon as possible.
Closes#11525.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62813 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Remove the test which prevented the generation of erase background events from
wxMSW::wxWindow::HandleEraseBkgnd(). Although it is true that native controls
mostly erase background on their own, there are exceptions: we must erase the
background of wxToolBar ourselves, for example. More importantly, there is no
reason to prevent the user code from defining wxEVT_ERASE_BACKGROUND handlers
for the native controls as this works just fine under MSW (although it doesn't
under GTK nor probably other ports...). So also add a test erase background
handler to the toolbar sample to verify that this does work.
Closes#11514.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62805 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The best default behaviour seems to be to use white background for multiline
text controls even when they're read-only, as in previous wx versions.
Also see #11521 which could be implemented to make this configurable.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62804 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit doesn't introduce any changes in the control behaviour, it simply
moves the existing method to the base class because it is not MSW-specific.
Also implement wxTextCtrlBase::GetClassDefaultAttributes() because if a class
implements GetDefaultAttributes() it should implement it as well.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62803 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is necessary to properly define MY_DLL_DECL as either WXIMPORT or
WXEXPORT depending on whether my_dll.h is included from DLL itself or from
outside it. Without this, MSVC generated warnings about inconsistent dll
linkage.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62802 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Rename old private wxGetModuleHandle() function to wxDynamicLibrary::
MSWGetModuleHandle() to allow its use in the dll sample.
This fixes the sample compilation with VC6 which lacks GetModuleHandleEx()-
related declarations.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62801 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using __stdcall before the return type results in a warning with VC6 and an
error with VC9, place it after the return type.
Also use wxSTDCALL instead of just __stdcall for potentially better
compatibility with other compilers.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62800 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The variable "lenChunk" was incorrectly used as the length of the wide string
chunk which could result in wrong output.
Worse, the output buffer could be overflown for the final chunk because it
didn't have to have enough space for the trailing NUL(s) in it.
Fix both bugs and added unit tests for them.
Based on patch by Kuang-che Wu.
Closes#11486.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62793 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't refer to the non-existent outputBuf parameter and don't imply that the
value of dstLen matters to decide whether we really convert or not -- only
whether dst pointer itself is NULL or not does.
See #11486.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62792 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't hardcode the string representation of the accelerators, it was
inconsistent with the rest of wxWidgets which used '-' while here a '+' was
used.
Closes#11512.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62791 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Calling out the user-defined wxThread dtor while holding gs_mutexDeleteThread
lock is a bad idea as it may result in deadlocks if the dtor deletes another
thread. Only lock the mutex directly before manipulating the data it protects.
Thanks to Neno Ganchev.
Closes#11501.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62781 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxLogChain::DoLogRecord() only called DoLogRecord() on the old logger but not
the new one when the new logger was the same object as wxLogChain itself as is
always the case for wxLogWindow. The result was that nothing was logged into
the window.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62777 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't fail loudly if the image file is not found (which can happen under Unix
if the image sample wasn't built yet or if we're not running the sample from
its own directory) but just don't create the bitmap.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62770 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Remove the assert added in r62101 (see #10917), it was wrong as the other
ports do not assert in this case. Instead, just ensure that the path we use
with the GTK+ native chooser is absolute.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62769 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Replace all occurrences of
@interface wxFoo : NSFoo
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
<NSProtocol>
#endif
which we used for protocols new in 10.6 with just
@interface wxFoo : NSFoo wxOSX_10_6_AND_LATER(<NSProtocol>)
which looks better and simpler.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62755 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Defining lfind as _lfind is not enough and a warning C4996 is still generated
by MSVC9 when the function is called.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62753 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Avoid dozens of warnings about "unsafe" use of the standard C library
functions in 3rd party code which are harmless and which we don't care about
in any case.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62752 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
