The base class already does exactly the same thing -- except that it also
accounts for the borders properly.
Also fix access for a couple of DoXXX() member functions which should be
protected and an event handler which can be private.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62821 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This fixes an assert in wxGenericStaticText which overrode
DoGetBestClientSize() but not DoGetBorderSize().
It would still be useful to implement DoGetBorderSize() in wxGTK (and other
ports) in general too as using wxGenericStaticText with non-default border
still doesn't work.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62820 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The handler for this event in the base class incorrectly changed the event
object of the original event instead of setting it for the event being sent to
the window children as it was supposed to.
Closes#11458.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62818 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Correct the change of r62814: only call SetMinSize() for non-top-level windows
as the user should be able to resize the top-level ones to be smaller than
their initial size.
This also fixes the GTK+ warning resulting from calling wxTLW::SetMinSize()
from the ctor, before the window is realized.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62817 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The change of r62306 broke the code which relied on the window created with a
given initial size to never become smaller than this size. This was to be
expected because the best size of such window is now (1, 1) and not its
initial size but we still need to preserve the old behaviour for compatibility
and also because it usually does make sense to avoid shrinking the window with
an explicitly specified initial size beneath this value.
So call SetMinSize() with the initial size explicitly now in wxWindowBase
ctor.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62814 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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
