This reverts commit de10f054c4 and a bunch
of commits improving it done since then:
6f888df474 (Restore button size calculation when not using manifest in wxMSW, 2021-04-24)
de10f054c4 (Improve calculating wxButton best size under wxMSW, 2021-04-08)
6f888df474 (Restore button size calculation when not using manifest in wxMSW, 2021-04-24)
75d508b6e6 (Fix regression in sizes of buttons with bitmaps in wxMSW, 2021-07-08)
051418ac00 (Fix recent wxMSW buttons with bitmaps appearance regression, 2021-08-26)
fbc6462375 (Fix a gcc warning introduced by the previous commit, 2021-08-26)
The reason for reverting is that using BCM_GETIDEALSIZE doesn't seem to
have any advantages compared to using our old code, as it doesn't take
the margins into account neither and we still have to add them ourselves
and so it's simpler to just always do it without using this message.
We often need the logical bitmap size when using it in size computations
involving window size, so add a function returning it directly to
wxBitmapBundle, similarly to wxBitmap::GetLogicalSize(), to avoid using
FromPhys() everywhere.
Also rename the existing wxBitmapBundle::GetPreferredSizeFor() to
GetPreferredBitmapSizeFor() to make it more clear that this is similar
to wxBitmap::GetSize() and so returns the size in physical units.
Closes#22056.
ImageData of a button can be reset. When this happens, make sure to unbind
the ImageData from the buttons event handler so no invalid access occurs when
the DPI changes.
This was already done for buttons using wxXPButtonImageData to store the image data,
also do it for buttons that use wxODButtonImageData.
When the DPI changes, recreate the bitmaps with the size corresponding to the new DPI.
Move m_btn to wxButtonImageData so it can be used for both ImageData implementations.
Avoid scaling the bitmaps by using the preferred size for them.
This results in significantly better appearance without any real
drawbacks in practice at 125% and 175% DPI scaling in the common case
when just a single and double-sized bitmaps are available, and still
seems to be acceptable at 150% scaling in this case.
Recreate wxImageList used for the bitmaps internally with the bitmaps of
the size corresponding to the new DPI.
This commit is best viewed with --color-moved git option.
Take wxBitmapBundle in wxButton::SetBitmapLabel() and related functions
in order to be able to associate several bitmaps to be used in different
resolutions with the button, instead of just a single bitmap.
Do this for consistency with the other ports and because this seems more
useful anyhow.
Update the documentation to make this behaviour more clear and document
this change as a (minor) incompatibility in wxMSW.
Also add more unit tests to check for this behaviour. Note this also
fixes the problem with the unit test added in the grandparent commit
under MSW.
Reverting the commits broke indentation, which resulted in
-Wmisleading-indentation from (recent) gcc, so fix it by indenting the
restored "if" properly.
See #13130.
Revert both 53eff92ea7 (Call AdjustForBitmapMargins() only once in
wxAnyButton, 2021-04-24), which was completely wrong and was due to not
reading the code attentively enough, and the subsequent 5d508b6e6 (Fix
regression in sizes of buttons with bitmaps in wxMSW, 2021-07-08) which
fixed the problem introduced by the first commit partly, but not
completely.
Closes#13130.
This fixes regression introduced in de10f054c4 (Improve calculating
wxButton best size under wxMSW, 2021-04-08) which didn't check whether
BCM_GETIDEALSIZE succeeded -- as we must do, because in some situations
(when using very old systems or not using a manifest even under newer
ones), it does indeed fail.
We can use BCM_GETIDEALSIZE message to get the size of the button that
best fits its text and image (if present).
It gives better results for text wxButton with wxBU_EXACTFIT style.
It looks only left- and top-aligned images stored in the image list
(BUTTON_IMAGELIST) are drawn with proper margins (with BCM_SETIMAGELIST).
For some reasons (bug in Win API?) margins for right- and bottom-aligned
images are applied only on one side of the image so the image drawn in
the button is misplaced in relation to the label.
It seems the only possible workaround for such images is to switch to
the owner-drawn mode and to draw the image manually in the proper location.
Closes#13130.
When wxButton is switched to owner-drawn mode we need to store its image
data in the dedicated wxODButtonImageData structure. We shouldn't use
in this case wxXPButtonImageData structure because it is dedicated for
native buttons and every time it's updated a BCM_SETIMAGELIST message is
sent to the button what is unnecessary action.
When button images are stored in the image list (BUTTON_IMAGELIST)
their margins should be set with BCM_SETIMAGELIST message.
BCM_SETTEXTMARGIN sets the margins around the text label
and not the image.
See #13130.
Use "relative pixels" (known as DIPs in wx) instead of dialog units, as
the latter ones don't scale correctly due to rounding errors when using
high DPI.
Also take into account the fact that the 1px invisible border around the
visible part of the buttons is not scaled by the standard control, so
don't apply scaling to this part when determining the best size neither.
Closes#18528.
This results in buttons being forced to be too tall when using high DPI
and is useless anyhow, as all callers of this function deal with the
height by increasing it to the minimum acceptable value already (or
discard it entirely in wxMessageDialog::AdjustButtonLabels()).
See #18528.
Don't use FromDIP together with ConvertDialogToPixels, because the font height
is already adjusted to the DPI.
Also limit the button height at higher DPI. Because the height determined by
ConvertDialogToPixels is higher than standard buttons use on Windows.
Closes#18528
Don't use ExtFloodFill() to extend the custom background colour to the
edges as this results in weird problems due to an apparent bug in nVidia
drivers, see #18387.
Instead, just extend the rectangle passed to FillRect(), which doesn't
look quite as good under Windows 10, but is pretty close, and shouldn't
suffer from the nVidia bug while also slightly improving appearance
under Windows 7.
Closes https://github.com/wxWidgets/wxWidgets/pull/1319
::GetThemeMargins() may fail if the custom theme being currently used
doesn't implement the required functionality, so initialize MARGINS with
some reasonable values before calling it, if only in order to avoid
using uninitialized (and so wildly wrong) margin values in this case.
Closes https://github.com/wxWidgets/wxWidgets/pull/1036Closes#18278.
Apply DPI scaling to the extra vertical margin added by this macro to
the font height.
This makes sense and results in wxTextCtrl (and other controls, e.g.
wxSearchCtrl) having the same height as native ones when using high DPI
too.
Note that this required adding wxGetEditHeightFromCharHeight() function
as one of the existing uses of EDIT_HEIGHT_FROM_CHAR_HEIGHT() wasn't
inside a wxWindow-derived class method and also adding wxUSE_GUI guard
around these GUI-only definitions as a function, unlike a macro, can't
be compiled without full wxWindow declaration in scope.
Owner-drawn buttons with multiline labels were always centered.
Fix this by handling their alignment explicitly when drawing them, as
::DrawText() doesn't do it for multiline strings.
Closes#18131.
Don't grey out the buttons text when they're implicitly disabled because
the parent TLW is disabled by MSW while showing a modal dialog, this
looked bad. Only grey the buttons text when they're really disabled at
wx level.
Closes#18011.
Remove various definitions and symbol declarations from
numerous files using msw/uxtheme.h to a single file.
When possible vssym32.h is included from the Windows SDK.
For older SDKs tmschema.h is included and missing symbols
are defined in msw/uxtheme.h.
This undocumented "private" class was used for various windows UxTheme
functions which are available since WinXP. As wxWidgets 3.1 is XP+ it
does not make sense anymore to load the theme functions dynamically.
Add wxMSWWinStyleUpdater and wxMSWWinExStyleUpdater helper classes which
allow writing code changing GWL_STYLE and GWL_EXSTYLE bits,
respectively, in a shorter and more clear way.
There should be no real changes in behaviour.
Prior to 2.9.2, if the focus bitmap was specified but current one wasn't, the focus bitmap was used for hovering as well.
This feature was entirely discarded in b4354db179 (see wxBitmapButton::DoSetBitmap) but it is still described in the documentation of wxButton's states and images. It seems it was removed unintentionally, so let's restore it.
The symbols in question are present at least since XP, and most of them since
Windows 2000, so remove preprocessor checks for them, they shouldn't be needed
when any remotely current compiler/SDK.
Take advantage of Windows 10's flat appearance to completely fill the
button's area with background color. This isn't as easily possible in
other versions and can't be done by e.g. enlarging the painted rectangle
because focus ring (which we don't want to override) may be thin or
thick depending on user settings.
MSW buttons are highlighted by the theme when the mouse hovers over
them. This servers as a feedback to the user that the button is
clickable, so it's desirable to preserve it even if the button uses a
custom background color.
Fix regression introduced by bd388e9827: bitmap
buttons could now be made significantly taller than the text control height if
their bitmap was big enough. Only make buttons taller if they wouldn't be tall
enough on their own, instead of always increasing their height, even if it's
already big enough.
Closes#17576.
