This static function parses a subset of the language tags described in
BCP 47 (see https://www.rfc-editor.org/rfc/bcp/bcp47.txt).
Use the tag, as specified by this function, rather than the locale
identifiers components under MSW, where this should allow us to use even
locales that can't be described using just language-script-region.
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.
This finally seems better than always creating some kind of impl object,
even if the locale isn't supported at all and makes all ports behave
consistently, as previously CreateForLocale() only returned NULL in
wxOSX implementation if the locale was unrecognized, but now all ports
do this (at least when locale_t and related functions are available
under Unix).
Also stop returning bool from Use(), as this resulted in initializing
wxLocale with any non-default language to fail under Mac: just ignore
the error here, as we always did it until now, because there is nothing
we can do about it anyhow.
This required changing CompareStrings() to be a method of wxUILocale
object, rather than just as a static function, as we must only allocate
the locale_t object once, and not during each to this function, as this
could make it unusably slow when using it as a comparison function when
sorting a large list of strings.
This is also more efficient under Mac, where we can similarly allocate
NSLocale only once and even marginally more efficient under MSW, where
we don't have to construct the locale string during each call. And,
under all platforms, it also simplifies code by separating this function
implementation from the initialization of wxUILocaleImpl.
Also document that case-insensitive comparison is not available under
Unix and adjust the tests accordingly.
Creating such objects (without using them for the UI) is supported under
all platforms, so allow doing it.
Note that this is only supported under Unix systems when locale_t and
related functionality is available, but this should be the case just
about everywhere by now.
Add a test (or, rather, replace an existing test which was disabled by
default) checking that we can now get locale information about any
locale, not necessarily the currently used one.
Use the recommended name-based NLS API rather than legacy functions
taking LCID.
Preserve compatibility with Windows XP by keeping the old code for now,
but it will be removed after 3.2.0.
Add Use() virtual function which can be used if the newly created
wxUILocaleImpl object should be used as the default UI locale.
Currently Use() is always called after creating a new wxUILocaleImpl, so
adding a separate function just seems to complicate matters needlessly,
but this won't be the case any more soon, when wxUILocaleImpl could be
created for using them for other purposes than making them the default.
No real changes yet.
Harmonize Mac and MSW versions by using case-sensitive comparison in
both of them by default, but allowing to use a flag to use
case-insensitive comparison instead.
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.
Add wxUILocale class providing functionality which can be implemented
portably for all major platforms, including macOS, and doesn't force
the change of the global C locale, unlike wxLocale.
See https://github.com/wxWidgets/wxWidgets/pull/2464
This is more consistent with EnableProofCheck() and allows to retrieve
the current state of grammar checking under macOS, which can be checked
by user and so can be useful to know.
Remove a separate "bool enable" argument of EnableProofCheck() and use
wxTextProofOptions::IsSpellCheckingEnabled() to decide whether the
checks should be enabled or disabled.
Also remove wxTextProofOptions ctor and provide named static factory
functions for creating the objects of this class with clearly defined
meaning.
This is tidier than using #ifdefs in the same common file and also
ensures that initializing wxLocale affects wxUILocale too, which will be
important for compatibility when the code elsewhere is modified to use
wxUILocale::GetInfo() instead of wxLocale::GetInfo() in the upcoming
commits.
This commit is best viewed with --color-moved git option.
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.
