React to the WM_DPICHANGED event and update the size of the child windows and
the top-level window. Scale the minimum and maximum window size to the new DPI.
Only react to WM_DPICHANGED when DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 is
used.
This is simpler to use than wxDisplay(window).GetPPI() which was used
instead of it so far in all ports and can be implemented more
efficiently for wxMSW.
Remove wxGetWinTLW, GetDPI already tries to get the top window.
Add MSWDoClientToScreen() and MSWDoScreenToClient() helpers and use them
with the correct HWND in DoClientToScreen() and DoScreenToClient()
overridden in wxSpinCtrl, i.e. the HWND of the "buddy" text control and
not the spin button, which is the main HWND of this control.
This notably fixes wxSpinCtrl::GetScreenPosition() which returned the
position of the spin button.
Closes https://github.com/wxWidgets/wxWidgets/pull/1454Closes#18455.
In wxMSW, a focused wxRadioButton is always checked, which meant that
checking a wxRadioButton while focus was not in the window containing it
and later giving the focus to that window could uncheck it by giving
focus to another wxRadioButton that had had it previously.
Fix this by adding WXSetPendingFocus() to wxMSW wxWindow and calling it
from wxRadioButton::SetValue() to ensure that when the focus is
regained, it goes to the newly checked radio button and not some other
one.
This replaces the previously used, for the same purpose, wxMSW-specific
wxTopLevelWindow::SetLastFocus(), so while this solution is not exactly
pretty, it's not worse than we had before, while being more generic.
Also add a unit test checking that things work correctly in the scenario
described above.
Closes https://github.com/wxWidgets/wxWidgets/pull/1257Closes#18341.
WNDPROC and FARPROC are not the same thing in MSW and it's wrong to use
WXFARPROC as the type of different window procedures we use.
Introduce WXWNDPROC which is more clear and correct and use it instead.
Also get rid of a few casts which are not necessary any longer.
Don't request touch event generation for all windows by default, this
has an inherent overhead and is not needed for 99% of the application
windows, so require calling EnableTouchEvents() explicitly to do it
instead.
Note that this requires properly initializing gesture recognizers in
wxOSX now that they're not always allocated, otherwise releasing them
when destroying the window would crash.
Don't repeat the same code for initializing events in several different
functions but put it in a helper InitGestureEvent() function and just
call it from the event-specific handlers.
This method was already provided by wxGTK and wxMSW, but not wxOSX nor
any other ports.
Provide a stub for it in wxWindowBase to allow user code to call it on
all platforms, there is no harm in that even if it doesn't (and can't)
do anything under macOS.
This method allows to use the Windows class to use for the window being
created instead of always using "wxWindow" or "wxWindowNR".
This can be useful to make it possible to handle some windows specially from
outside the application, e.g. use specific class names for accessibility
purposes as will be done by the next commit.
Determine which class name to use in MSWCreate() caller instead of doing it
partly there and partly in MSWCreate() itself, which used to add the "NR"
suffix if necessary -- now it doesn't do this any more and just really created
the window using the given class.
No real changes, just prepare for future enhancements.
Don't define BeginRepositioningChildren() and EndRepositioningChildren() at
all in this case instead of defining them as "do nothing" functions because
BeginRepositioningChildren() still needs to return a bool, so the old code
didn't compile and we would need to add another "#else" to fix this -- instead
make it simpler by just not compiling at all in this case.
This will make it possible to reproduce the default "Enter" key functionality
from elsewhere.
Almost no changes yet, the only minor change is that we now wouldn't try to
"click" any windows using DLGC_DEFPUSHBUTTON dialog code but which are not
really buttons -- but then this shouldn't ever happen anyhow.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
This parameter is redundant, we can find out whether a menu is a popup one or
not from the menu itself, assuming that we always have a valid wxMenu pointer
for popup menus events, which really should be the case (we may not have one
for the events from system menus).
This allows to handle popup menu events case in the base class version of
MSWFindMenuFromHMENU() which will allow to reuse it from places other than
DoSendMenuOpenCloseEvent() without code duplication now.
There should be no changes to the behaviour, this is just a simplification.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78227 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This ended up being broken due to an interplay between different unrelated
changes (at least r15120 and r41134) which were both correct, but didn't work
well together and resulted in not only preventing IsDialogMessage() from
handling ESC, but also our own accelerator tables.
Fix this by doing the check for IsDialogMessage() brokenness in
MSWProcessMessage() itself, just before calling it, instead of doing it in
MSWShouldPreProcessMessage() which is (and must be) called before
MSWTranslateMessage() which checks for accelerators using ESC.
Closes#3813.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77071 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Contrary to MSDN implications, at least some of these messages are not
actually sent to the TLW for popup menus, but to the owning window or
even its parent window (!).
Move the handling of these events from wxTLW to wxWindow. Move menu
depth tracking to wxFrame, because it only makes sense for frame's
menus and move DoGiveHelp() from wxTLW to wxFrame.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76721 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This must be done both at wxWidgets and MSW level, otherwise changing the ID
results in window not recognizing itself as the recipient of the messages sent
to it by Windows.
Closes#3697.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76672 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't compare __VISUALC__ with versions 1200 (VC6) and earlier, such tests are
always true or always false now that we don't support VC6 any more, so just
remove them simplifying the code.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76548 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is just a refactoring of wxMSW code to make it possible to use deferred
window positioning from other places in subsequent commits.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74066 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We must use physical coordinates for the brush origin to account for the
coordinates offset in scrolled windows, so add MSWAdjustBrushOrg() and call it
from MSWGetBgBrushForChild().
Closes#14917.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73495 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxPanel didn't inherit the background colour set for its parent any more in
wxMSW because its HasTransparentBackground() didn't return true unless the
panel was a child of wxNotebook. This was wrong because not only themed
notebook background should be inherited but also any solid background
explicitly set for a panel parent.
Fix this by returning true from MSWHasInheritableBackground(), which is used
by wxPanel::HasTransparentBackground() under MSW, if the window has an
explicitly set and inheritable background colour.
Closes#13487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69348 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit just refactors the code without changing anything in its
behaviour and will be followed by the real changes in the next one.
The new function just handles the message, without calling MSWDefWindowProc()
if it wasn't handled. This allows to call it and determine whether the message
was really handled and only continue processing it if it wasn't.
Notice that while in theory this shouldn't be necessary because the return
value of MSWWindowProc() should indicate whether the message was handled or
not (0 meaning that it was, for most messages), in practice it doesn't work
because many standard controls window procs return 0 even for message they do
nothing with, e.g. "up down" control always returns 0 for WM_CHAR messages
even it it only really handles the arrow keys.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68327 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This event is sent by wxMSW after the default handling of WM_CHAR has taken
place. It can be used to define an event handler triggered by key presses and
having access to the new value of the control, updated to take the last key
press into account.
This event will be used by auto-completion implementation for wxMSW only for
now.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67512 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Factor out MSWGetCustomBgBrush() from MSWGetBgBrushForChild(). This is useful
as in the vast majority of cases the parent window will want to use the same
background brush for all of its children so it doesn't really care about the
concrete child passed to MSWGetBgBrushForChild() and we can adjust the brush
to the child origin in the common code instead of asking each derived class
overriding MSWGetBgBrushForChild() to do this.
This doesn't change anything but will make the upcoming changes to wxPanel
background painting simpler.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67250 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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
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
With MSWSetTransparentBackground() hack only the panel which was the immediate
child of wxNotebook (i.e. its page) inherited the notebook background but not
its children. This resulted in jarring background discontinuities when nested
panels were used.
Fix this by inheriting notebook background in all child panels by testing for
the return value of the parents MSWHasInheritableBackground() method in
wxPanel::HasTransparentBackground() recursively.
Closes#12317.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65238 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
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
Forward declaring enums is illegal in standard C++ and while MSVC allows this
as an extension, it doesn't compile with g++.
Just include wx/settings.h instead.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62993 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
