Trying to give all the remaining space after allocating enough to the
other columns to the first one doesn't work well with wxDataViewCtrl,
which tries to do the same thing, but with the last column, so we
actually get some strange mix of behaviours, with both the first and
last columns changing size after the control itself is resized.
Stop fighting with wxDataViewCtrl and just let it to its own thing.
Closes#17476.
Declare the variables just before using them (and also initialize them
at the same time); use more readable variable names; fix braces style
and add a comment explaining why do we do all this in the first place.
No real changes.
Don't crash trying to use an uninitialized font in
GetPartialTextExtents() later if the font was created using
CreateFont(sizeInPixels, facename, flags) overload.
Closes#18021.
Returning true/false from wxCairoFontData::Apply() to indicate whether
Pango should or not be used was not very clear, so prefer to test for
the font explicitly in the code calling Apply() and make Apply() itself
void, consistently with the method with the same name in the other
classes.
Also avoid calling it at all from GetTextExtent() when using Pango, this
is completely unnecessary as the text colour doesn't have any bearing on
its extents.
Also use static_cast and const_cast as appropriate instead of C-style
casts.
Although it's the same color the control already had, overriding it
can have unexpected consequences, such as overriding the text selection
colors with GTK3. Fixes invisible wxSearchCtrl selection with GTK3.
Use wx_is_at_least_gtk2(minor) instead of gtk_check_version(2, minor)
because it is more clear and also works as expected (i.e. returns true)
when using GTK+ 3 instead of creating difficult to notice bugs in the
code by failing the version check in this case.
See #18004.
Verify that the active loop didn't change during this object lifetime as
otherwise we could deactivate a different event loop from the one we
installed.
It's still a programming error to write code which doesn't destroy
wxGenericProgressDialog early enough, but at least now "just" assert and
leak memory in this case instead of resetting the active event loop and
hanging the program.
Closes#17983.
Remove another redundant line of code from wxGenericProgressDialog::
Create(), there is no need to call GetParentForModalDialog() again when
we just did it to initialize m_parentTop, just use the latter directly.
The line setting m_parentTop directly was mistakenly left over even
after 7e08367534 added the call to
SetTopParent() just above it.
Remove it now (better late than never), it's redundant at best and even
wrong if the top level parent can't be used as the dialog parent because
SetTopParent() checks for this but this line did not.
If the new message is longer than the previously shown one, increase the
dialog size to fit it, instead of truncating the message. Still don't do
anything if the new message is shorter to avoid unwanted constant
changes in the dialog size if the message keeps changing.
This is the original patch proposed in #10624, which it really makes
sense to apply now because it makes the generic version match the
behaviour of the native one under MSW (and the behaviour of the native
version cannot be changed).
See #10624.
Allow entering times such as 23:59:59 which were previously mistakenly
flagged as invalid due to off by one error in the comparison in the
validation function.
Fix comparing items with checkboxes in wxTreeListCtrl and make it
simpler to correctly implement item comparison in other
wxDataViewCtrl-derived classes.
See https://github.com/wxWidgets/wxWidgets/pull/558
Export this class, which was only used internally by wxTreeListCtrl
before, so that user code can use it for its own columns with custom
wxDataViewCtrl models.
Override DoCompareValues() to handle values of "wxDataViewCheckIconText"
type which is not handled by wxDataViewModel::Compare() itself.
This ensures that the items with checkboxes are sorted by their (text)
contents instead of by the order of their addresses in memory as was
done for them, as for any unknown values type, previously.
SetSelections was clearing the previous selection, invalidating the
current item, but didn't set it after selecting the new items.
This was causing issues in keyboard selection, e.g. pressing Shift+click
didn't select all the items between the selected and the clicked ones.
Fix this by making the last item of the new selection current, which is
the expected behaviour considering that SetSelections() should be
equivalent to calling SetSelection() with all items one by one.
Signed-off-by: Anil Kumar <anilkumar8753@gmail.com>
Closes https://github.com/wxWidgets/wxWidgets/pull/557
It doesn't make much sense to require all the graphics backends to
create wxGraphicsPen from either wxPen or wxGraphicsPenInfo when the
former can be handled just once in the common code.
So do just this, leaving CreatePen() overload taking wxGraphicsPenInfo
where the real pen construction takes place and implementing
wxGraphicsPen creation from wxPen in the common wxGraphicsContext code.
This is not 100% backwards-compatible as any code inheriting from
wxGraphicsRenderer and overriding its CreatePen() will now be broken,
however this should be extremely rare (there is no good reason to
inherit from this class in the user code) and result in compile errors
if it does happen.
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.
The vertical scrollbar position could be updated (at least wit wxGTK) to
not show the last item any longer, after deleting the previously last
item, which was very annoying from the user point of view as the focus
was visually lost.
Avoid this by explicitly calling EnsureVisible() to prevent this from
happening.
