These functions were confusingly named as they work with MSW (virtual) key
codes and not character codes, rename them to better indicate what they do.
They also don't need to be in wx/msw/window.h included by all wx code when
they are only really needed in a couple of files, so move them to a private
header.
No changes in behaviour.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65523 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Only set Unicode key code if the event corresponds to a character key and set
it to (newly added) WXK_NONE for the other ones to avoid nonsensical values in
it for e.g. "Home" key presses.
Also set non-Unicode key to WXK_NONE for the characters that can't be
represented in the current locale. This is consistent with wxGTK and avoids
conflicts between special key values and Unicode keys.
Clearly document the above behaviour.
Notice that implementing the correct behaviour in wxMSW involved untangling
previously interwoven WM_KEY{DOWN,UP} and WM_CHAR messages handlers. Clearly
separate them now as they get different input (key codes for the former,
characters for the latter) and especially don't try to convert from both kinds
of input using a single wxCharCodeMSWToWX() function. As this function doesn't
need to distinguish between keys and characters any more it can simply return
the converted value in all cases instead of returning 0 sometimes to indicate
a character value instead of a key. Simplify the code using this function
accordingly.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65522 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
KF_EXTENDED is defined in Windows headers as the mask for extracting the
"extended" bit from LPARAM of the keyboard messages. Use it instead of
explicitly writing less clear "1 << 24".
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65520 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Simulating keys such as WXK_END resulted in WXK_NUMPAD_END event being
generated instead of the expected WXK_END one.
Fix this by returning from wxCharCodeWXToMSW() whether the key code is a
normal or extended one and use this to set KEYEVENTF_EXTENDEDKEY in
wxUIActionSimulator::DoKey().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65518 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No changes, just use more clear variable name ("keycode" instead of "id") and
anonymous namespace instead of static keyword.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65513 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
LPARAM is a 64 bit type in Win64 and doesn't match the size expected by "%l"
printf format specifier. Instead of showing it as a 32 bit number in 32 bit
build and 64 bit in 64 bits, just truncate it to the lower 32 bits in any case
for now, this should be enough for the diagnostic messages.
Closes#12242.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65010 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We used a pointer into the result of wx_str() for a temporary string which was
clearly wrong. Store the string we're manipulating to ensure that this doesn't
happen.
This in particular fixes keyboard navigation in the menus with owner-drawn
items.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64919 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxDELETE[A]() functions which automatically NULL out their arguments after
deleting them instead of doing it manually.
Closes#9685.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64656 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Check for the transparency of the window background in MSWGetBgBrush() itself
and let MSWGetBgBrushForChild() just return the brush to be used.
This required adding a MSW-specific hack to wxPanel to allow inheriting
background of wxNotebook by its children which is slightly ugly but is exactly
what we need to do in this case and makes the rest of the code much simpler.
Also add a possibility to set the background of the page containing the
control being tested to the widgets sample to test for background inheritance.
This shows problems with wxSlider and wxRadioBox backgrounds but they're not
new with this patch.
Closes#12057.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64372 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't duplicate the code for setting (and unsetting, which was forgotten by at
least wxGTK) the popup menu invoking window in all ports but do it in the base
class PopupMenu() itself.
Also add a helper wxMenuInvokingWindowSetter class which ensures that the
invoking window will be unset in any case.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64143 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The client size of maximized windows which hadn't been shown yet isn't
computed correctly by wxMSW because WM_NCCALCSIZE returns too small values for
some reason. Attempts to fix this were unsuccessful so just ensure that the
window is re-laid out using the right size from WM_SIZE it receives when it is
shown instead of using the wrong pending size.
Closes#11762.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64115 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The old code was messy because it handled both top level and child windows at
wxWindow level when they need quite different treatment. This resulted in
several errors: first, wxWindow versions of WidthDefault and HeightDefault
were used to determine the initial size even of top level windows which was
clearly wrong as it created tiny windows (20*20). Second, CW_USEDEFAULT could
be used for child window for which this shouldn't be done.
Fix this by making MSWGetCreateWindowCoords() virtual and overriding it in
wxTopLevelWindow. This makes the code much simpler and more obviously correct.
Also make MSWGetCreateWindowCoords() void, as nobody was using its return
value anyhow (and the old version also had a bug in it and wrongly returned
true when default size was passed to it).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64101 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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
