g++ warns about initialized extern variables so separate the declaration from
the initialization to avoid this warning.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@63270 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Failure to create a wxPaintDC in EVT_PAINT handler resulted in many serious
and difficult to debug problems under wxMSW. We used to document that the user
shouldn't do it but this wasn't enough (see #11648). We could also assert if
we detected that a handler didn't create a wxPaintDC but it seems better to
just handle this case gracefully for consistency with the other platforms.
Add wxDidCreatePaintDC global variable which is reset before generating
wxPaintEvent and set to true when ::BeginPaint() is called from wxPaintDC
ctor and validate the update region of the window ourselves if it wasn't set
(meaning that wxPaintDC wasn't created).
Update the documentation to emphasize the link between EVT_PAINT handlers and
wxPaintDC but without saying that wxPaintDC object must always be created in
the handler as this is not true any more.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@63229 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Do use TBSTYLE_FLAT and TBSTYLE_TRANSPARENT (the former actually implies the
latter) for MSW toolbar as it is the only way to avoid the flicker of toolbar
buttons. These styles were disabled before because of lack of understanding
about how they worked: with them, the toolbar supposes that its parent takes
care of erasing its background but wx didn't do this (in fact wxFrame did
accidentally erase toolbar background because of the use of Win32 client
rectangle, including tool/status bars, instead of wx client rectangle,
excluding them, in wxWindowMSW::DoEraseBackground(), but it didn't do it
correctly).
Now we allow hooking WM_ERASEBKGND events processing in a parent window by a
child one and use this to handle toolbar background erasing in toolbar itself.
We still prevent the native toolbar from drawing dummy separators and always
erase the area occupied by them ourselves and thus avoid the flicker entirely.
The only remaining flicker in the toolbar sample is that of embedded
wxStaticText control. It does appear with correctly transparent background and
bitmaps with alpha channel also (still) are drawn correctly in wxStaticBitmaps
embedded in the toolbar.
Finally, we still use solid background brush for toolbar but we can easily use
a themed background if really desired, there is just a single function to
change to do it (MSWGetToolbarBgBrush()).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62971 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Pass wxWindow instead of HWND to it as in most cases we already have wxWindow
for the HWND we have and calling wxFindWinFromHandle() once more is
unnecessary.
This also makes the code of MSWGetBgBrushForChild() slightly simpler.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62932 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Not using FVIRTKEY results in problems in non-US keyboard layouts and, in
fact, we were already always using it because wxCharCodeWXToMSW() returned
true in its output IsVirtual argument most of the time.
Just do it always now and also remove IsVirtual parameter with badly (if at
all...) defined meaning from wxCharCodeWXToMSW() as it's not used anywhere any
longer.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62913 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
Calling Show/HideWithEffect() with this effect is the same as calling just the normal Show/Hide().
This is convenient as it allows to use the same API, whether with effects or without them.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62267 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Handle wxBG_STYLE_TRANSPARENT as wxBG_STYLE_PAINT and wxBG_STYLE_COLOUR as
wxBG_STYLE_ERASE instead of asserting (and almost surely crashing next, as
this assert is in the code called when the window is repainted and so will be
called again when the assert dialog is shown resulting in reentrant assert).
Closes#11208.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62049 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Call GetBestSize() from wxWindowMSW::DoSetSize() so that it works correctly
for the classes which only override DoGetBestClientSize() and not
DoGetBestSize() itself, such as wxStaticText.
Closes#11096.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61785 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
DoGetClientBestSize() returns the best size of the client area, without
accounting for the border which is done by GetBestSize() itself and
DoGetBorderSize() called from it.
Use DoGetClientBestSize() in wxStaticText (where it was done
insideDoGetBestSize() before) and in wxListBox, to fix its height calculation.
Also use correct height of listbox items as returned by the control itself
instead of trying to guess it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61169 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
