Prior to 2.9.2, if the focus bitmap was specified but current one wasn't, the focus bitmap was used for hovering as well.
This feature was entirely discarded in b4354db179 (see wxBitmapButton::DoSetBitmap) but it is still described in the documentation of wxButton's states and images. It seems it was removed unintentionally, so let's restore it.
If neither wxCAL_SUNDAY_FIRST or wxCAL_MONDAY_FIRST was given, use
wxDateTime::GetFirstWeekDay() to automatically determine the preferred
day.
This changes the earlier default behaviour, which was to use Sunday
if not otherwise specified. However, the wxGTK native calendar control
ignored this behaviour anyway.
This function tries to determine the preferred first day of week to use in
calendars. The procedure for obtaining this information is highly
platform-dependent, and is not possible on all platforms; in that case
Sunday is used as the fallback value.
Implementations are included for MSW, OSX, and Linux.
It is a synonym for wxIMPLEMENT_ABSTRACT_CLASS and not
wxIMPLEMENT_DYNAMIC_CLASS as it was wrongly stated.
Also avoid duplicating the documentation of the other macro and just
refer to it instead.
This doesn't work, as non-blocking sockets implementation requires
dispatching events generated by them, which is only possible from the
main thread event loop, and it's better to be upfront about it rather
than failing mysteriously later.
Apparently various text wrapping modes are not supported natively by
NSTextView (apart from word wrapping which is used by default) and
non-default wrapping has to be implemented in the custom code.
To wrap lines at any character, NSLineBreakByCharWrapping style should be
applied at any text change to the entire text stored in NSTextStorage
associated with NSTextView. This is done in DoUpdateTextStyle() method
which is called from controlTextDidChange() when text is modified by
the user, or SetStringValue() and WriteText() when text is set
programmatically.
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.
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.
wxPropertyGrid::ExpandEscapeSequences() function should convert all valid
escape sequences (\r, \n, \t, \\) to the corresponding single characters
(CR, LF, TAB, backslash, accordingly) and
wxPropertyGrid::CreateEscapeSequences() function should do the reverse
operation and convert these raw characters to the corresponding escape
sequences.
Closes#17896.
This feature to show/hide alpha values and opacity selector (slider) is
already implemented under wxGTK and for generic wxColourDialog.
For the sake of backward compatibility, this feature is enabled here by
default (through the corresponding property of wxColourData).
A simulation of context menu event by handling directly EVT_RIGHT_UP was implemented in wxSTC in 451c5cc7b9, but later on, EVT_CONTEXT_MENU generation in wxOSX was fixed in 524c47aa3a so simulation is no longer necessary and this event can be directly handled in wxSTC.
Rename relatively new enum value wxTASKBAR_JUMP_LIST_DESTIONATION to
wxTASKBAR_JUMP_LIST_DESTINATION as well as a private function containing
the same typo.
Return false and avoid calling OnChangedViewList() if the view wasn't present
in the first place.
This is not, strictly speaking, backwards compatible, but most of the existing
code doesn't seem to check the return value of RemoveView() at all and it's
hard to imagine that someone would rely on it returning true when removing a
non-existent view, so in practice this changes seems to be safe.
Closes#17888.
