No real changes, just clean up sources by removing trailing spaces from
all the non-generated files.
This should hopefully avoid future commits mixing significant changes
with insignificant whitespace ones.
Add wxGridCellDateRenderer and wxGridCellDateRenderer which can be used
for the grid cells containing only dates, without times.
Also add wxGrid::SetColFormatDate() convenience function.
Refactor wxGridCellDateTimeRenderer slightly to reuse its code.
Closes https://github.com/wxWidgets/wxWidgets/pull/1101
As wxDataViewColumnList was never public, it should be fine to not
define it any more and use a vector instead.
This makes the code more clear and also marginally more efficient.
Previously, the last column couldn't be effectively resized at all, as
its size was always automatically set to the remaining width of the
window after subtracting the widths of all the previous columns. Now
this is only done if this remaining width is greater than the width
given to the column by the user or by the program.
Effectively, this means that the user can now drag-resize the column to
increase its size (at the price of showing the horizontal scrollbar).
See #18295.
This reverts commit 24054c95d8 as it
actually should be possible to increase the size of the last column,
even if this shows the horizontal scroll bar.
Dragging a column header in a wxHeaderCtrl and dropping it past the
rightmost column resulted in a crash due to accessing a column with
invalid index.
Fix this and correctly move the column to the last position when this
happens instead.
This bug notably affected dragging columns in wxGrid.
Closes https://github.com/wxWidgets/wxWidgets/pull/972
There doesn't seem to be any point in storing pointers to wxBitmap or
wxIcon and storing the objects directly allows to avoid an extra heap
allocation and all the code dealing with freeing memory when replacing
or removing images from the list, making things much simpler.
Also use wxVector<> for storage instead of the obsolete and ugly
wxObjectList.
There shouldn't be any user-visible changes.
Cache labels for "Next>" or "Finish" button in wxWizard so that their
translations stay consistent throughout wizard's lifetime: previously,
this button could use a label in a different language if the currently
used translations have changed since the wizard creation, as this label
was recreated on every page change, unlike the other labels which were
only translated once in the very beginning.
Closes https://github.com/wxWidgets/wxWidgets/pull/1000
Use wxVector<wxListLineData*> instead of WX_DECLARE_OBJARRAY().
This modernizes the code and allows to get rid of the static variables
previously used for sorting as now we can use std::sort().
Closes https://github.com/wxWidgets/wxWidgets/pull/924
This solves backward incompatibility problem introduced in 2d8bbbe3c9.
The name of base class for grid header renderers hierarchy is restored
to be wxGridHeaderLabelsRenderer. This introduces another problem: now
wxGridCornerHeaderRenderer is derived from wxGridHeaderLabelsRenderer,
not vice versa, as it was before. But it is considered less disruptive
change, compared to base class rename.
Now, every header cell can have a label, including the corner one,
so wxGridHeaderLabelsRenderer::DrawLabel() was moved up one level
in the inheritance chain. Class names were changed accordingly.
Actual storage of corner label is delegated to a grid table class,
just because it is already done that way for column and row labels.
This basically removes the "adv" library, even though it's still
preserved for compatibility with user make/project files referring to
it.
It is done because the distinction between "adv" and "core" was never
really clear (e.g. why wxTreeCtrl was in core but wxTreeListCtrl in
adv?) and it prevented some core classes from using adv ones.
Ignore all the mouse events other than "left up" while dragging to avoid
releasing the mouse and ending the dragging operation too soon.
This required non-trivial refactoring of the code which hopefully should
also make it slightly more clear by centralizing high level logic in
ProcessGridCellMouseEvent() itself and calling various helper functions
from it instead of spreading this logic over the entire call tree.
The code still remains pretty confusing and rewriting it to use
wxMouseEventsManager (which would need to be generalized first to become
a template class using arbitrary item type instead of just "int", as
now) would undoubtedly do it a lot of good.
Closes#18186.
No real changes, just refactor the code to extract the part of
CancelMouseCapture() which can be useful not only when the mouse capture
is lost unexpectedly, but also when we release it of our own volition,
into a separate function.
Make the (originally) auto-generated code of this dialog slightly more
readable by replacing some auto-generated variable names with more clear
ones.
Also avoid using FindWindow(), this is useless and we already have the
window pointers.
Closes https://github.com/wxWidgets/wxWidgets/pull/872
Revert 1de107c037 and remove the focus
event handler which duplicated and interfered with the handler inherited
from this class to make sure that we get wxEVT_{SET,KILL}_FOCUS for the
objects of this class.
Unfortunately these events now come in pairs, due to an extra artificial
event generated by wxComboBoxExtraInputHandler::OnFocus(), which is
still wrong -- but arguably less wrong and more useful than not sending
them at all.
This allows showing radio buttons in wxDataViewCtrl easily and natively.
Notice that this approach, adding an extra function to the existing
renderer class instead of creating some new wxDataViewRadioRenderer (see
https://github.com/wxWidgets/wxWidgets/pull/809), was finally chosen
because it is simpler to implement and, more importantly, because it
will be more natural to generalize if/when we also add a 3-state
check/radio renderer.
Closes https://github.com/wxWidgets/wxWidgets/pull/853
There is no need to override this virtual function, if the control size
changes, a wxEVT_SIZE event is generated in any case, resulting in a
call to LayoutControls() without explicitly calling it from here.
There doesn't seem to be any reason to have these flags, which duplicate
the visibility state of m_searchButton and m_cancelButton respectively.
Also update the buttons visibility immediately in ShowSearchButton() and
ShowCancelButton() instead of doing it in LayoutControls() as before,
which was confusing as laying out is not supposed to show/hide anything.
Finally, return true, not false, from IsSearchButtonVisible() if the
button is actually visible because there is an associated menu, even if
ShowSearchButton(false) had been called. This seems more logical and
makes the code simpler, but we need to check whether the native Mac
version also behaves like this or not.
No other changes in behaviour.
For some reason lost in the depths of time (but probably just a typo)
(but probably just a typo) (but probably just a typo) (but probably just
a typo), SetItem() overload taking the column index returned "long" and
not "bool", even though the actual return value was always "true" or
"false" (or even just always "true" in the case of the generic version).
Change it to return "bool" for consistency with the other overload and
because this just makes more sense and shouldn't break any existing code
due to the implicit conversions between bool and long.
Also document the return value meaning.
Closes#18153.
There doesn't seem to be anything wrong with just showing the popup menu
in this window itself and this avoids the need to do any coordinate
adjustments, which didn't work correctly for the menus shown over the
header window after the previous commit (and hadn't worked correctly for
the menus shown over the non-header area before it).
See #18133.
The default alignment of the text in wxSpinCtrl was changed to "right"
in 7e4952db83, which added alignment
support (see #10621), but this made it inconsistent with the native
up-down control under MSW and, perhaps more importantly, with spin
controls created from XRC as the default style was never modified there
and did not include wxALIGN_RIGHT.
Resolve this inconsistency by reverting to left-aligning the text by
default.
The horizontal static line was added to separate the button from the
child window when visible, but this didn't seem very useful and looked
bad and was inconsistent with the native GTK+ implementation as well as
similar controls commonly used under MSW (wxOSX already disabled the
static line use).
Just remove it to make things simpler and better looking.
Closes https://github.com/wxWidgets/wxWidgets/pull/804
Previously this method was only available in the generic wxDataViewCtrl,
move it to the base class to make it possible calling it in portable
code and document it.
Closes#14617.
