This function can now be implemented relatively straightforwardly
(although it does require an extra check under Mac), so add it, as it
can be generally useful and we're also going to need it for our own
tests in the upcoming commit.
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.
This function can be used for all GetInfo() items, so using it is
simpler than the code in the Unix version of wxLocale::GetInfo() which
uses either it or localeconv(), and there should be no real drawbacks to
using it nowadays as it should be available everywhere.
No real changes yet.
This is convenient, as it allows using a simple string such as "en" as
an argument to the functions taking wxLocaleIdent and rely on implicit
conversion, whereas previously explicitly writing either wxString("en")
or wxLocaleIdent("en") would be necessary.
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.
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 dialog is non-modal and so using GetParentForModalDialog() for it
is not quite right, because this function checks that the candidate
parent window is visible, which may not be the case for a modeless
dialog parent, as the dialog isn't necessarily going to be shown
immediately, but may well be shown later, after showing its parent.
And not allowing to use the not yet shown parent was also inconsistent
with the native MSW version which didn't have any problem with this.
So fix this by adding new GetParentForModelessDialog() function and
using it for this modeless dialog instead. This required slightly
refactoring wxDialog code to allow reusing most of it between the old
GetParentForModalDialog() and the new function.
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.
There doesn't seem to be any need to have these functions here as the
base class implementation already does exactly the same thing (i.e.
nothing at all).
Use native support for grammar checking in NSTextView.
As we're not passing wxTextProofOptions to the lower level function,
this functionality now depends on wxUSE_SPELLCHECK, meaning that even
the previously existing MacCheckSpelling() function is not defined any
more when wxUSE_SPELLCHECK is set to 0. This is not completely
backwards-compatible, but hopefully shouldn't be a problem in practice
and shouldn't break any existing applications which can't disable the
just added wxUSE_SPELLCHECK.
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.
Keep the entire wxTextProofOptions argument on the same line.
Remove unnecessary WXUNUSED() in the declarations of the function in
wxMSW/wxGTK headers.
No real changes.
It does no real harm to set it to 1 and this avoids the need for the
platform checks in setup.h files, simplifying things (although it does
require checking for GTK 3 in the code compiled for both GTK 2 and 3, as
gtkspell library can only be used with GTK 3).
Define various macros used in the test code (or in the headers included
from it) as nothing when wxDEBUG_LEVEL==0.
Also don't define a helper function used when asserts are enabled in
this build to avoid clang warnings about unused function.
The existing ToString() is not flexible enough to be used in wxGrid,
which supports specifying the width (and not just the precision) as well
as using formats other than "%g" and "%f" which are the only ones
supported by the existing function.
Note that currently the implementation simply calls wxString::Format()
and then adjusts the decimal separator, but it could, in principle, use
wxUILocale methods for formatting the floating point numbers using
native platform functions for doing this, e.g. CFNumberFormatter under
macOS.
This ensures that we use the decimal separator corresponding to the UI
locale of the application, rather than C locale, so that e.g. comma is
used under macOS even if setlocale() is not used.
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.
No real changes, just allow wxUILocale code to use this struct without
including the full wx/intl.h.
This commit is best viewed with --color-moved git option.
In a756ed93c2 (wxWebViewEdge: Improve wxEVT_WEBVIEW_LOADED, 2021-08-17)
usage of additional interfaces was added. This adds their interface IDs
for non VISUALC compilers.
Also sorted the definitions alphabetically, use "--color-moved" git
option to see the actual changes.
Closes https://github.com/wxWidgets/wxWidgets/pull/2472
It seems unlikely that we're ever going to need this function in any
other classes inheriting from wxTextEntry (i.e. wxComboBox) and both
existing implementations are for wxTextCtrl only, so define this
function there.
If really necessary, we can always lower it to wxTextEntry later, while
moving it in the other direction wouldn't be easily possible due to
compatibility concerns.
This commit is best viewed with git --color-moved option.
This allows each control have its own undo history, independent of the
other ones, as expected by the wx API, rather than using an undo manager
shared by all controls in the same TLW.
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
It doesn't cost us anything to define the compatible names, and there is
no real advantage for the existing application code in using the new
names, so define them without WXWIN_COMPATIBILITY_X_Y checks around
them, to avoid forcing unnecessary changes in the application code when
upgrading to wx 3.2.0.
This commit is best viewed ignoring whitespace-only changes.
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 MSW creating a wxSpinCtrl with a range of, say, 1..10 and the
default initial value of 0 sets its initial value to 1 (i.e. the closest
valid value) as expected, but the generic version still set it to the
invalid value of 0, which was unexpected, inconsistent and not useful.
Fix the generic version to follow MSW behaviour now and add a test
checking for this.
No real changes, just make it possible to use these constants without
including the entire wx/intl.h.
Note that the existing headers including wx/intl.h need to keep
including it, unfortunately, as not doing it any longer would break
compilation of any code including them which relies on _() or
wxGetTranslation() being defined after including e.g. wx/dc.h. This was,
of course, never guaranteed, but in practice it worked for a very long
time, so don't break it now.
This commit is best viewed with --color-moved git option.
