In InsertColumn(long, const wxListItem&) a line was split inside a
referred overloaded method signature which prevented doxygen to
recognize and link the referred method.
In InsertColumn(long, const wxString&, int, int) non-existing
Insert(long, const wxListItem&) overload was referenced instead of
InsertColumn(long, const wxListItem&).
Clsoes https://github.com/wxWidgets/wxWidgets/pull/1279
This commit partially reverts 17055fb8c6
which resulted in asserts when destroying dialogs with buttons, one of
which had focus, see https://github.com/wxWidgets/wxWidgets/pull/1245
This happened because wxGetTopLevelParent() returns NULL when the parent
TLW was already half-destructed, resulting in an assert, while the
original code still returned NULL in this case, but did it silently,
which is the right thing to do here as we can't avoid being called
during the parent TLW destruction.
Closes https://github.com/wxWidgets/wxWidgets/pull/1268
Reset the number of buttons to skip deleting the old buttons in
wxToolBar::Recreate() as these buttons don't exist any more (having been
created in the old control) and trying to delete them just results in
debug error messages from TB_DELETEBUTTON.
Recreating the toolbar tried to offset the new toolbar window being
created by the size of the existing toolbar, when it was set up as the
main frame toolbar. Luckily, this didn't work because getting the size
of a wxWindow without a valid HWND failed, but it resulted in debug
warning messages and was a wrong thing to do in the first place.
Fix this by hiding the old toolbar before destroying it, this suffices
for the parent frame not to use it for the client area calculations.
If neither main widget nor connect widget is focusable (which notably
happens when they're the same anyhow, as is the case for wxChoice, for
example), still use the main widget as mnemonic instead of not using any
mnemonic at all.
This fixes activation of a wxChoice preceded by wxStaticText by pressing
the key combination corresponding to the label mnemonic, which didn't
work previously.
Due to a wrong "else" in RealizeTabOrder() implementation, we could set
the mnemonic widget for a previous widget using mnemonics (i.e.
wxStaticText or wxStaticBox) rather than the one closest to the actual
control activated by the mnemonic.
This truncates the control with GTK+ 3 where 40 or 60 pixels is never
enough for its width (even without speaking about high DPI displays) and
results in tons of GTK+ warnings.
This is a minor optimization and can significantly reduce flicker in a
not uncommon case when SetCellValue() is used to refresh all or many of
the grid cells if only few of them actually change.
See #9717.
Closes https://github.com/wxWidgets/wxWidgets/pull/1276
Don't assert in wxBoxSizer when both alignment flags and wxEXPAND are
used together if wxSHAPED is also used, as such flag combinations may
make sense and so shouldn't be forbidden.
Add a unit test checking that this is allowed.
Since 0185d61a2c wxToolBar height is
increased if the controls don't fit in it rather than decreasing the
size of the controls, which results in different appearance than in the
previous versions, so document this as well as the advice for restoring
the old behaviour.
This wastes less space in the toolbar and looks better and is more
compatible with 3.0 (although not totally so, but this is intentional
as 3.0 didn't use any margins at all, which looked bad).
Resetting the insertion point position to 0 after calling
wxTextCtrl::SetValue() or ChangeValue() which didn't really change the
control contents was unexpected, as such calls are supposed to be
"optimized away", and this was indeed the case under wxMSW and wxOSX,
but not in wxGTK.
So change wxGTK to follow the other ports, add a unit test checking for
this behaviour and officially document it.
As a side effect, this ensures that the numeric validator classes don't
reset the insertion point position to 0 on every focus loss under wxGTK,
as happened before.
This works around gcc -Wredundant-decls warning that was given (if
explicitly enabled) when both wx/vector.h and wx/utils.h were included.
The workaround is ugly, but it doesn't seem worth it to introduce a
separate wx/qsort.h header just for this single function, which seems to
be the only other way to fix this.
Closes https://github.com/wxWidgets/wxWidgets/pull/1271
Even if it's not supposed to do anything, avoid calling
wxTextCtrl::ChangeValue() completely if the text contents doesn't
actually change. This should be slightly more efficient and avoids any
chance of bugs such as the one resulting in the insertion point being
still moved to the beginning of the text even if it doesn't change in
wxGTK currently (see https://github.com/wxWidgets/wxWidgets/pull/1270).
In this case wx-specific RTTI is used and GetWxTypeId() method was
overridden without using wxOVERRIDE, which resulted in dozens of
warnings for each translation unit.
In wxMSW, a focused wxRadioButton is always checked, which meant that
checking a wxRadioButton while focus was not in the window containing it
and later giving the focus to that window could uncheck it by giving
focus to another wxRadioButton that had had it previously.
Fix this by adding WXSetPendingFocus() to wxMSW wxWindow and calling it
from wxRadioButton::SetValue() to ensure that when the focus is
regained, it goes to the newly checked radio button and not some other
one.
This replaces the previously used, for the same purpose, wxMSW-specific
wxTopLevelWindow::SetLastFocus(), so while this solution is not exactly
pretty, it's not worse than we had before, while being more generic.
Also add a unit test checking that things work correctly in the scenario
described above.
Closes https://github.com/wxWidgets/wxWidgets/pull/1257Closes#18341.
Don't set the focus to the window the rich tooltip refers to in its
ShowFor() method because this was inconsistent with plain tooltips and
also could result in infinite recursion if the window decided to show
its tooltip when it got focus.
Closes https://github.com/wxWidgets/wxWidgets/pull/1265
Apparently, ScrollTo() can be called when processing keyboard input in
the control before its initial resize and hence before scrolling is
initialized and in this case per-unit scroll units are still 0, so
dividing by them is not a good idea.
Just avoid scrolling in this case.
Closes https://github.com/wxWidgets/wxWidgets/pull/1262
Currently the Scintilla message SCI_REGISTERIMAGE is mapped to
wxStyledTextCtrl::RegisterImage(int, const wxBitmap&). This makes
RegisterImage a manually defined method and passes the bitmap directly
to the listbox instead of first converting to an XPM.
To backfill the message map, SCI_REGISTERIMAGE is now mapped to a new
method overload RegisterImage(int, const char* const*). The new method
accepts XPM data instead of a wxBitmap.
Currently the Scintilla message SCI_MARKERDEFINEPIXMAP is mapped to the
wxStyledTextCtrl::MarkerDefineBitmap method. This has two
drawbacks. First this requires the XPM image handler be loaded before
this method can be called. Second, any alpha data except for opaque and
transparent is lost in the conversion to XPM format.
Instead have MarkerDefineBitmap be a manually declared method but
reimplemented it in a way similar to how the SCI_MARKERDEFINERGBAIMAGE
message works. The new implementation preserves alpha data if it exists.
To backfill the message map, the SCI_MARKERDEFINEPIXMAP is now mapped to
a new method MarkerDefinePixmap(int, const char* const*). The new method
accepts XPM data instead of a wxBitmap.
The ListBoxImpl::RegisterImage in PlatWX.cpp is supposed to accept an
XPM and convert it into a useable form. For wxWidgets, the useable form
is obviously a wxBitmap. According to the Scintilla specification, the
function should accept both a copy of an XPM file and a set of XPM data.
Currently RegisterImage uses the the wxWidgets XPM image handler. This
has 2 drawbacks. First it requires that the XPM handler is loaded before
the function can be called. Second, the function only accepts a copy of
an XPM file and does not work with XPM data.
Instead use wxXPMDecoder. This class can be decode both types of input
and can be used to build a wxBitmap.
Add a unit test for a special case of a wrap sizer min size caclulation.
Test wxWrapSizer::CalcMinFromMinor function for this case, when a wrap
sizer used inside a sizer with the same alignment.
