Check for Windows 10 was implemented as check for version 6.4 but the final
version of Windows 10 actually returns 10.0.
(this is a backport of c87c432033)
Unlike the similar (identical?) SetUserScale(), this function didn't call
RealizeScaleAndOrigin(), add it now for consistency.
(this is a backport of 75794137f605328e2d3e6a45106f30b8ac268cbb from master)
See #17053.
Use wxUIntToPtr() to suppress the warning, we know that the cast here is safe
because Windows uses only pointers fitting in the UINT range for the menu (and
other) handles.
Set ms_isThemeEngineAvailable to -1, meaning that we need to reinitialize
themes, instead of false, meaning that themes are not available.
This fixes problems when the library is initialized, shut down and then
initialized again.
Closes#17023.
Don't ignore errors (this resulted in warnings in optimized builds because
variable "hr" containing the error code to was assigned but never used) and
don't leak memory in the (admittedly unlikely) case an error really occurs.
Also don't duplicate the code for creating a one element SAFEARRAY<VARIANT>,
extract it into a helper function.
Don't cast NMHDR::code field to int, this cast was added in the previous
millennium, probably to work around the wrong definition of NM_DBLCLK in some
ancient MinGW headers, but nowadays all MinGW distributions (tested with
MinGW 4.8.1, MinGW-64 4.9.1 and TDM-GCC 4.9.2) define it correctly and so
using this cast results in a warning -- just remove it to get rid of it.
This class doesn't really need a virtual dtor as it's never used
polymorphically, but add it to avoid g++ warnings about it.
(this is a backport of 8ad1e2698f from master)
The flicker was only visible under Windows XP or when using a class theme
and was due to mis-positioning the status bar initially in PositionStatusBar().
Fix this by adjusting its position by the toolbar offset before calling its
SetSize().
Closes#16705.
(this is a backport of 8d12e07453 from master)
This fixes a regression introduced in 45e216b (see #14279):
wxBitmapComboBox must be higher than a normal wxComboBox if it has big
enough bitmaps. Closes#16690.
This is the backport of 7e869a5 from master.
Previously it only handled wxALIGN_CENTRE, also the documentation switched to
wxALIGN_CENTRE_HORIZONTAL in 72e88d8ea3 and
preceding commits.
See #16943.
Handlers for this event expect to get wxSpinEvent but wxMSW and wxGTK1 sent an
object of base wxCommandEvent class which resulted in invalid memory access in
the handlers when using the derived class methods such as Veto().
See #16948.
Don't mix signed/unsigned integers in arithmetic operations when normalizing
wxDC scale factors: variable holding GCD value should be of the same type as
variables holding devExt and logExt to avoid wrong results of /= operation
when dividend is a negative value.
Closes#16908.
This was broken due to a wrong cast from WPARAM (i.e. 32 bit unsigned int in
Win32) value containing the ID to WORD (i.e. 16 bit unsigned short) which
truncated the ID value.
Notice that MSDN documents the requirement for the IDs to be positive, but
negative IDs seem to work, at least with Windows 7, after this fix.
Closes#16880.
Use GET_{X,Y}_LPARAM() to extract them from the event position, which handle
negative coordinates (and coordinates can perfectly well be negative when
using multiple displays) correctly, unlike {LO,HI}WORD().
Closes#16812.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@78419 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add Windows-specific wxMSWDisableSettingHighDPIAware() function then can
be called before startup (i.e. wxEntry() call) to disable wxWidgets'
handling of DPI awareness. This is useful for code embedded in non-wx
applications as well as for purely wx application that are not
HiDPI-ready (although the latter has the option of forcing
dpiAware=false in the manifest).
See also https://groups.google.com/d/msg/wx-dev/Z0VpgzCY34U/f1FfPqGDppMJ
and #16116.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@78406 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Creating the status bar before the menu bar but associating it with the frame
after creating the menu bar resulted in a status bar of completely wrong height.
Fix this by enforcing the default height on the status bar when it's attached
to the frame.
Closes#10956.
[This is the backport of r76417 from trunk.]
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@77949 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.
[This is the backport of r77071 from trunk.]
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@77948 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't use mask and alpha together, this results in visual artefacts and masks
are unnecessary with RGBA bitmaps anyhow.
The only potentially problematic remaining case is mixing bitmaps with alpha
and mask inside the same image list (as we need to indicate whether we use the
mask or not when creating it), but this should probably be rare and in the
meanwhile we can at least RGBA bitmaps with image lists, which includes doing
this implicitly when they are used as button bitmaps.
Also refactor wxBitmap code to extract part of CopyFromIconOrCursor() to allow
reusing it in the newly added MSWUpdateAlpha().
See #11476.
[This is the backport of r75567 from trunk.]
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@77947 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use position, not the ID, to find the native menu items to allow the code in
wxMenuItem::SetItemLabel() and DoSetBitmap() to also work with submenus and
not just the normal items.
Closes#16246.
[This is the backport of r76676 from trunk.]
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@77945 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Apparently at least one printer driver doesn't report the memory needed by its
own DEVMODE struct correctly, resulting in a crash due to a buffer overflow
when printing using it.
Work around this by allocating slightly more memory than what we really need.
Closes#16274.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@77522 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Ensure that the order of stops is consistent with the documentation and other
platforms behaviour, i.e. they are counted from inside to outside of the
circle and not vice versa, which happens to be the GDI+ convention.
Closes#16443.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@77482 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Passing an invalid initial directory to wxDirDialog resulted in using the old
style Windows directory selector dialog instead of the new style (file dialog
like) one, which was unintentional, as incorrect initial directory shouldn't
prevent the dialog from being shown.
Fix this by handling ERROR_FILE_NOT_FOUND error specifically and still showing
the new dialog, just without the (non existent) initial directory value, in
this case.
Closes#16430.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@77081 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Just use the native ::MapWindowPoints() to do the coordinate transformation
instead of doing it ourselves: we did it wrongly by inheriting the layout
direction from wxTheApp instead of from the parent window, so fix this in the
best possible way by not doing it at all and just relying on Windows to do it
for us.
In particular, this corrects the display of wxStatusBar in RTL frames.
Closes#15031.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76980 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The keyboard handling code could decide to activate a button which wasn't
currently visible at all, e.g. because it was on a non-current, and hence
hidden, page of a wxBookCtrl. This didn't make any sense, so check for the
button visibility before activating it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76978 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Handle WM_CTLCOLOR correctly for them, this wasn't done before because the
code assumed that sub-windows (i.e. HWNDs which belong to the same logical wx
control) were always children of the main window, but they could also be its
siblings (like in at least the two above mentioned cases).
Account for this case in wxControl::DoMSWControlColor() too now.
Closes#12271.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@76950 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
