The old API didn't make any sense for the most common case when both the
user name and password need to be stored, as it required providing the
user name as input, which couldn't work (but somehow this went
unnoticed for more than a year...).
Fix this by returning the username, and not only the password, from
Load() instead of taking it as parameter and removing this parameter
from Delete() as well.
Also improve the documentation, notably include a simple example of
using this class.
Notice that this is a backwards-incompatible change, but the old API was
really badly broken and didn't appear in 3.1.0 yet, so the breakage is
both unavoidable and, hopefully, shouldn't affect much code.
Nevertheless, a special wxHAS_SECRETSTORE_LOAD_USERNAME symbol is added
to allow testing for it if necessary.
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.
Somehow recent changes to this file added CRs (^M) characters to the
ends of some lines, remove them to avoid having a mix of Unix and DOS
EOLs in the same file.
No real changes.
No real changes, just replace wxT() with wxS() as wxBasicString ctor now
that it takes wxString and not "const wchar_t*" and remove the now
unnecessary explicit "wxString()".
Don't try to write a general purpose class, but provide just the methods
that we need in our code.
This fixes the bug added in 294436c8bb
which resulted in a crash because a literal string, not a BSTR, was
passed to wxBasicString ctor.
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.
