When there is open an editor for some property and in the same time
wxPropertyGrid layout is changed (due to the adding or removing a property,
sorting), it is necessary to recalculate the actual position of the active
editor to display it in the cell dedicated for the edited property. Under
some platforms the position of the edit control is shifted within the cell
and we have to take this shift into account in repositioning process.
Because actual value of the shift depends on the platform and on
the particular control, it is convenient to determine actual shift when
the editor is created and use this value whenever repositioning is done.
Close#17912.
Position of the combo box editor associated with properties having custom
bitmaps like e.g. ColourProperty, needs to be adjusted in order to display
edited text at the same position as the text which is displayed as
a property value prior to the editing.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
at the same position as the text which is displayed as a property value
prior to the editing.
Position of the combo box editor associated with properties having custom
bitmaps like e.g. ColourProperty, needs to be adjusted in order to display
edited text at the same position as the text which is displayed as
a property value prior to the editing.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
string at the same position as the text which is displayed as a property
value prior to the editing.
Generalize the "vc_msw*" exclusions under the other directories
(samples, demos, tests, utils) to all compilers and versions, like it
was already done for the directories under build/msw.
The window was still resized even if its size didn't really change,
which, in particular, unexpectedly resulted in closing its drop down if
it was shown.
Fix this by moving the code dealing with the different interpretation of
the control height between wxMSW and MSW (for the former, it's just the
height of the visible part, while for the latter it includes drop down
as well), from wxChoice::DoSetSize() to DoMoveWindow(). This allows the
base class DoSetSize() to correctly filter out calls not really changing
the size, while still setting the height correctly when it does change.
See #17075.
See https://github.com/wxWidgets/wxWidgets/pull/389
Previously, all MSW-specific stuff like calling SetThreadLocale() and
SetThreadUILanguage() was only done when initializing wxLocale from a
wxLanguage value, but not when using a string name for it.
Fix this by implicitly calling Init(wxLanguage) from Init(wxString) if
we can find the language corresponding to the given name, and if the
other parameter is not incompatible with it.
Don't call wxSetlocale() in DoInit() any more, this was redundant when
it was called from Init(wxLanguage) overload.
Add new DoCommonPostInit() called from both Init() overloads after
setting the locale in whichever way they do it to avoid code
duplication.
As a side effect of this change, the error message given if the locale
can't be set is the same now independently of the ctor/Init() overload
used (previously it differed depending on whether a wxLanguage or the
name of the language as string was passed) and it's always logged using
wxLogWarning() and not it in one case and wxLogError() in the other one.
Simplify the code by just using "retloc != NULL" as success indicator
until the call to DoInit() instead of keeping a separate "bool ret"
variable in sync with "retloc".
Instead of calling wxLanguageInfo::GetLocaleName(), which called
setlocale() at least thrice (first to query the current locale, second
to try to change it and third to restore the original locale) and then
calling setlocale() again if it succeeded, use the new TrySetLocale()
method which calls setlocale() just once and doesn't require calling it
again in the caller.
This makes the code slightly more efficient but, more importantly,
shorter and more clear.
Try to make code less confusing by avoiding defining a variable in
platform-independent part of the code and then actually using it only in
platform-specific code.
Simplify the code by not checking for language == wxLANGUAGE_DEFAULT in
wxLocale::Init(): this can't happen because we use the system language
when passed wxLANGUAGE_DEFAULT as parameter and return false immediately
if we can't determine the system language.
Check if setlocale() really works with the name of the returned locale
and return empty string if it doesn't.
This fixes problem with setting locale when using old MSVC or MinGW CRT
under new (Vista+) MSW versions, as the CRT doesn't support the locale
names returned by LOCALE_SNAME and we need to fall back on
LOCALE_SENGLANGUAGE.
Optimize calling SetLabel() with the same label as the current one, this
seems to happen quite often in practice and results in flicker, so check
for it explicitly.
Adjust the size and position we're about to set before comparing them
with the current ones, otherwise the result of the comparison could be
wrong when width and/or height are -1.
See #17075.
macOS returns "cccc" (stand-alone weekday name) as a part of the
preferred date+time format for Finnish, and possiblly others. This was
not handled at all by wxTranslateFromUnicodeFormat(), and the user
saw the raw "cccc".
Similarly, handle stand-alone month name ("LLLL").
Closes https://github.com/wxWidgets/wxWidgets/pull/518
To avoid collisions with boost and c++ standard library using the assert macros starting with two underscores is the default under these new SDKs. Since they already existed in our minimum deploment SDK we can switch them safely.
This function doesn't compile currently because CreateFromHICON() is
wxMSW-only, so disable it it to at least let wxGTK compile for now, even
if the real solution would be to implement CreateFromHICON() for wxGTK
too.
Closes#17875.
Use an alternative and arguably simpler (at least with real-life
applications, where settings are somewhat more complex) way of handling
the differences between platforms in the preferences sample: instead of
executing completely different code under different platforms, always
update the local copy of the settings immediately and just propagate, or
not, it to the application-level settings depending on the current
platform.
This costs an extra copy of the settings object on each change, but this
shouldn't be a problem in practice, and OTOH results in using mostly the
same code under all platforms, reducing the probability of
platform-specific bugs and avoiding any code duplication between the
event handlers and TransferDataFromWindow().
Make the sample slightly more realistic by adding a MySettings struct whose
fields are updated the dialog and also make it more visual by showing the
current values of (some) settings on the screen.
Re-enable alignment support for wxDataViewCtrl cells in wxOSX which was
previously disabled just to allow the library to compile in 32 bits.
Closes https://github.com/wxWidgets/wxWidgets/pull/377
75831d232c removed all references to this
function, but left the function itself, resulting in -Wunused-function clang
warnings (and compiling an unused function, of course).
Take NSView* in the callback used by [NSView sortSubviewsUsingFunction:context:]
only when using 10.12 SDK, but not when using earlier ones, as the callback
was still taking just "id" in them.
Define wxCLRDLGG_USE_PREVIEW_WITH_ALPHA as either 0 or 1 instead of using an
expression involving "defined" for it as the latter provoked many clang
-Wexpansion-to-defined warnings, which were harmless but very annoying.
Use underscores on them to show that they are different from properties or
local variables (in pure Objective C they would actually start with
underscores, but this is not a good idea in C++ code) and avoid conflict
between a member name and "wxAlignment" type name, which was confusing.
