Work around what seems like a bug in StretchBlt() implementation by
applying an extra offset to it when using RTL layout and revert an
earlier attempt to fix this problem for wxMemoryDC used in wxNotebook
code from 6614aa496d (fix for tabs drawing in RTL (patch 1552881),
2006-10-21).
Closes#19190.
Remove conditions from MSW themed text drawing that prevent multi-lines
from being rendered properly and instead always use DT_TOP alignment
for multi-lines.
This fixes a regression occurring since 90ba137f20 (Work around text
extent differences resulting in clipped text, 2021-07-26) with themed
Vista+ :
Non-top aligned multi-line text gets rendered as a single line because
of DT_SINGLELINE being used if the height of the drawing rect and
multi-line text happen to be equal. This occurs on the "Variable line
height" page of the dataview sample, which calculates its cell height
by multiplying the text extent by the number of lines in the text (a
requirement with wxMSW, not wxGTK).
Removing the conditions also exposes top aligned multi-line themed text
to drawing beyond the drawing rect, which actually makes it behave more
like wxGTK and wxOSX as well as wxMSW non-themed drawing as they try to
render text fully without regard for the bounds of the drawing rect.
Closes https://github.com/wxWidgets/wxWidgets/pull/2470
We need to reset the default button using DM_SETDEFID too, otherwise
calling DM_SETDEFID later, when setting the new default button, seems to
restore BS_DEFPUSHBUTTON on the previous default button (but only if its
ID is positive, which probably explains why this bug went unnoticed for
so long), resulting in having 2 buttons with BS_DEFPUSHBUTTON in the
dialog.
Closes#19245.
This commit is best viewed ignoring whitespace-only changes.
Previously the edge event ContentLoading was used which was
triggered earlier than DOMContentLoaded. This event wasn't
available in earlier SDK versions.
Minimum required SDK version is now:
1.0.705.50 (Released 2021-01-25)
Fixes#19202
See https://github.com/wxWidgets/wxWidgets/pull/2468
The same value of 80px was used in both the generic and MSW versions of
wxListCtrl, so introduce a symbolic name for it and define it only once,
similarly to how it's already done for wxDVC_DEFAULT_WIDTH and
WXGRID_DEFAULT_COL_WIDTH.
No real changes.
Under at least some versions of Windows 10 with wxDVC themed text can be
clipped horizontally because of discrepancies between the text extent
as drawn by DrawThemeTextEx() and calculated with GetTextExtent()
earlier.
Work around the issue by always trying to use GetThemeTextExtent() in
DrawItemText(), not just for alignment of multi-line strings, and adjust
for any width differences similar to the existing adjustment for height.
See #18487.
Revert b642747fd2 (Fix right aligned text position in wxDVC on MSW with
system theme, 2015-09-30) which in wxRendererXP::DrawItemText() mimicks
the off-by-one with right alignment of wxDC::DrawLabel() that got fixed
by the previous commit.
There's not a similar change copying wxDC::DrawLabel()'s former
off-by-one behaviour with wxALIGN_BOTTOM that would need reverting.
Both alignments now result in the same text positioning with both
drawing functions.
When using non-TOP vertical alignment with wxRendererXP::DrawItemText()
either DT_VCENTER or DT_BOTTOM gets passed to DrawThemeTextEx() but
without the DT_SINGLELINE flag which is required for those alignment
flags to take effect, resulting in text always being top aligned.
Fix by passing DT_SINGLELINE when using either alignment, but only for
single lines as multi-lines are rendered as a single line with invisible
newline character. Draw multi-line text using top alignment and deal
with vertical alignment ourselves, using GetThemeTextExtent() to get
an accurate extent of the text.
Comment in wxRendererXP::DrawItemText() could be interpreted as
DrawThemeTextEx() being available for some XP editions but it is Vista+
only, so correct it.
This already worked with the generic version, but silently failed with
wxMSW, so make it work with wxMSW too as it doesn't cost much and makes
wxListCtrl behave in the same way under all platforms.
Also document that SetImageList() can be used before the window is
created.
It was impossible to give focus to the actual web view in wxWebViewEdge
by keyboard navigation or programmatically with wxWebViewEdge::SetFocus().
Fix it by calling CoreWebView2Controller::MoveFocus() in the wxWebViewEdge's
wxEVT_SET_FOCUS handler.
Closes https://github.com/wxWidgets/wxWidgets/pull/2444
We accidentally ended up with two functions doing the same thing, since
DoGetBorderSize() was added in 743b426605 (Added DoGetClientBestSize()
and use it for a couple of controls in wxMSW., 2009-06-22), as we
already had GetWindowBorderSize() added even earlier in 333d70525c
(added wxWindow::GetWindowBorderSize(), 2006-11-25), so remove the
redundant non-public function and use GetWindowBorderSize() everywhere.
This does change the behaviour of GetWindowBorderSize() in wxMSW, wxGTK
and wxUniv, as it now does what DoGetBorderSize() used to do, but this
should be an improvement, as DoGetBorderSize() implementation was more
precise.
wxComboBox::MSWShouldPreProcessMessage() didn't take into account many
keys that must be handled in wxComboBox even if they're used as
accelerators, including plain (i.e. without Ctrl modifier) Delete, Home
and End that are used by the embedded text control, if there is one.
Fix this by reusing wxTextCtrl::MSWShouldPreProcessMessage() which
already handled these keys correctly, by moving it to wxTextEntry, which
can be used from both classes.
Also add a check for wxCB_READONLY to prevent overriding the
accelerators using the keys that the combobox doesn't need when there is
no text control in it.
Closes#19227.
We cannot assume that axis-aligned clipping box in local coordinates will
remain axis-aligned box in device coordinates so we need to take into
account all 4 corners of the clipping rectangle to create a polygonal
clipping region in device space.
Closes#19228.
Simplify wxComboCtrl code by always using wxPopupTransientWindow if it's
available instead of various platform-specific workarounds that
shouldn't be needed any longer.
See https://github.com/wxWidgets/wxWidgets/pull/2423
No real changes, just use RAII wrapper instead of doing manual memory
management in wxMSW printing code.
We still use a raw pointer for m_devMode, but changing this would be
more involved, so leave it be for now.
Use the same scaling function as elsewhere instead of using
ceil/floor().
Provide wxRescaleCoordWithFrom specialization for int to allow using it
with just single coordinates too.
They're probably not that useful in application code, which should just
use wxDPIChangedEvent::Scale() instead, so move them to a private
header instead of making them part of the public API.
This is more concise and less error-prone than multiplying/dividing DPI
values manually.
No real changes except, maybe, in wxSlider code where the rounding was
done differently before for some reason.
This function was always called after calling CreateTextCtrl() and
couldn't be called at any other moment, so it didn't make much sense to
have it as a separate function, just install the custom input handler
when (re)creating the text control.
This simplifies the derived classes code.
Don't use wxClientDC in WM_NCCALCSIZE handler as creating it results in
another WM_NCCALCSIZE in wxUniv due to the call to DoSetClippingRegion()
in its wxClientDCImpl::InitDC().
Using simple WindowHDC is also a small performance gain and is all that
we need as we just need some HDC for this window and should have
probably been done like this even back in a047aff270 (Added
wxBORDER_THEME..., 2007-08-07) in which handling WM_NCCALCSIZE was
added.
Closes#19221.
The new method is currently supported in Qt, Cocoa, MSW ports (i.e. all
major ones except for wxGTK).
Keyboard example updated with a "Repeat" column.
Closes https://github.com/wxWidgets/wxWidgets/pull/2414
Using c_str() for arguments to wxString::Printf(), Format() and
wxLogXXX() is useless since wx 2.9 days, so simply remove them.
No real changes, this is just a (long due) cleanup.
DoDrawSpline() implementations for all ports work for the number of points
>= 2 (for 2 points there is drawn a straight line) so we need to add checks
whether this requirement is met.
See #19172.
Instead of implementing MSW-specific code to handle HDC for GDI+ context
directly in wxGCDC delegate acquiring/releasing HDC to underlying
wxGraphicsContext. Decoupling GDI+-specific code from wxGCDC will allow
us to implement handling HDC in other graphics renderers in a clean way.
They were incorrectly interpreted as mnemonics when drawing
wxCheckListBox items, which didn't make sense and was inconsistent with
the other ports and even wxListBox in wxMSW itself.
It also affected wxRearrangeCtrl under MSW, which uses wxCheckListBox
for its implementation.
Closes#19201.
Consistently check that the index is valid in all ports, instead of
using hard-coded 255 rather than the actual number of colours in some of
them and forgetting to check that the index is positive in others.
Closes#19198.
