Add new macros wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN_DEF_COPY() and
wxDECLARE_NO_ASSIGN_DEF_COPY() and use them instead of
wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN() and wxDECLARE_NO_ASSIGN_CLASS()
respectively to ensure that we declare a (default, if possible) copy
ctor in the classes declaring an assignment operator to avoid clang
warnings about not doing it.
The old API seems unnecessarily complex, it is simpler to just let the
application call ShowSortIndicator() itself from its
wxEVT_LIST_COL_CLICK handler, which needs to be defined anyhow in order
to actually sort the items, rather than require it to enable sort
indicator, explicitly set it initially and then remember to not set it
any longer in response to the column clicks.
Also make RemoveSortIndicator() non-virtual and implement it simply as
ShowSortIndicator(-1) because this actually simplifies the code too.
Don't use "const int" or "const bool" for parameter types, the "const"
here is ignored and using it is inconsistent with all the rest of the
library.
No real changes.
Put the code common to all wxListCtrl implementations in the common base
class instead of duplicating it in wxMSW, wxQt and generic versions.
No real changes yet, this is a pure refactoring which prepares for the
upcoming changes.
Override OnImagesChanged() to call UpdateImageListIfNecessary() even in
wxGenericTreeCtrl for now, although in the future it would really make
sense to stop using wxImageList in its implementation and just use
wxBitmapBundle directly instead.
wxMSW is the only one which really needs an image list, as it's required
by the native control.
Also update the sample, even though it doesn't look very nice because
its icons are only available in a single size, so we have to always
scale them.
Replace direct use of wxImageList with the use of wxWithImages, which
will make adding support for using wxBitmapBundle later simpler.
In fact, this already somewhat simplifies the code by removing the need
to manually take care of m_ownsImageListXXX flags.
We must call SetInitialSize() in Create() in order to take the size
argument passed to ctor/Create() into account -- it was completely
ignored previously.
But calling SetBitmap() must not change the initial size, as it can also
be done later, so just change the current size there instead (which is
consistent with wxMSW version and original behaviour, so keep it like
this, even though it's not totally clear if all ports do it).
Remove the now unused wxGenericStaticBitmap::GetBitmapSize().
Instead of defining them, slightly differently, in all the non-MSW
ports, define them once in wxStaticBitmapBase.
No real changes, this is just a simplification.
Don't leave m_useMask and m_scaleFactor uninitialized -- even if this
probably doesn't matter, call Create() to make sure they have
well-defined values for the default-constructed objects.
Add wxUILocale class providing functionality which can be implemented
portably for all major platforms, including macOS, and doesn't force
the change of the global C locale, unlike wxLocale.
See https://github.com/wxWidgets/wxWidgets/pull/2464
This ensures that we use the decimal separator corresponding to the UI
locale of the application, rather than C locale, so that e.g. comma is
used under macOS even if setlocale() is not used.
It doesn't cost us anything to define the compatible names, and there is
no real advantage for the existing application code in using the new
names, so define them without WXWIN_COMPATIBILITY_X_Y checks around
them, to avoid forcing unnecessary changes in the application code when
upgrading to wx 3.2.0.
This commit is best viewed ignoring whitespace-only changes.
Under MSW creating a wxSpinCtrl with a range of, say, 1..10 and the
default initial value of 0 sets its initial value to 1 (i.e. the closest
valid value) as expected, but the generic version still set it to the
invalid value of 0, which was unexpected, inconsistent and not useful.
Fix the generic version to follow MSW behaviour now and add a test
checking for this.
This was removed in 415f080c80 (Split wxGrid RANGE_SELECT event into
SELECTING and SELECTED, 2020-07-27) without preserving it for
compatibility. Do define it now, just as it was done for the non-CMD
equivalent of this macro EVT_GRID_RANGE_SELECT.
Also update the documentation to fix a typo from e2f316b19d (Mention
that wxEVT_GRID_RANGE_SELECT{ED,ING} are new in 3.1.5, 2020-08-18).
Use 2 separate functions instead to make the code more clear, as passing
false for indicate the refresh shouldn't be done was quite confusing.
Also get rid of a separate RefreshAll() which was called only from
RecalculatePositions().
No real changes.
Add an assert to this function checking that the index is valid before
using it with wxGridOperations::GetLineStartPos(), and actually avoid
calling the function when this is not the case to avoid assertion
failures when wxEVT_GRID_CELL_LEFT_CLICK is handled in user code.
Also add comments clarifying the preconditions for calling various
drag-related functions.
Closes#19218.
This makes several methods that didn't have any effect before work
correctly, including SetToolTip(), whose effect is now shown in the
sample, but also SetCursor() and SetLayoutDirection().
Some methods would now actually work too well: SetForegroundColour() and
SetBackgroundColour() implementations in wxCompositeWindow apply to all
sub-windows, but in wxDataViewCtrl they are only supposed to affect the
items, but not the header, so we need to override them to prevent the
base class version from being used. It is still preferable to explicitly
disable these two methods and inherit all the other ones (including any
possibly added in the future) from wxCompositeWindow to implementing all
the methods manually in wxDataViewCtrl itself.
Move this function, and the associated constant, to common code.
This required moving wxSpinCtrlDouble::Create() implementation to the
source file, but there are no real changes.
wxSpinCtrlDouble::SetIncrement() should increase the number of digits if
necessary because not doing it would be inconsistent with the initial
determination of the number of digits in the ctor and would actually
lose the digits displayed, but it seems unnecessary to decrease the
number of digits and it might be surprising, so don't do it.
Add a test for this behaviour and document it.
This is consistent with using the value of the increment specified in
the ctor for setting the initial number of digits, it was surprising
that creating the control with some value of the increment (e.g. 0.1)
and calling SetIncrement(0.1) later resulted in very different outcomes,
as in the former case the value was shown with a digit after the period
while in the latter case only the integer part was shown.
This also makes the behaviour compatible with that of the previous
versions of the generic wxSpinCtrlDouble, which used "%g" to format the
number before the changes of edc553870f (Fix displaying wxSpinCtrlDouble
values with default precision, 2020-05-18), as they did show the
fractional part even in the latter case.
Add a test checking that this works as expected: before this commit, the
test failed with "1 == 1.2" and "1 == 1.23" errors.
Make this part of SetDigits() reusable in order to be able to also use
it in DetermineDigits() now and in SetIncrement() in the upcoming
commit.
No real changes yet.
It doesn't seem right to leave it unchanged when increment is outside of
[0, 1] interval, we should still set it to something in this case.
And doing this makes it unnecessary and redundant to initialize m_format
in Init(), as it will be always done when DetermineDigits() is called
from Create() anyhow.
This allows to retrieve the current contents of the text entry part of
wxSpinCtrl.
For now provide a stub in the base class, will be made pure virtual
later.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
After the previous commit the coords stored by wxGridCellWithAttr have
become redundant as the coords are now also stored as part of the key
used for an attributes map. With then only an attribute remaining in
wxGridCellWithAttr it can be removed completely, letting the value of
an attributes map point directly to a (ref-counted) attribute instead.
Revert 8535cde836 (Remove apparently unnecessary m_hasExplicitFont,
2020-07-14) and make 9cd3ab5ebd (Improve wxGenericTreeCtrl colours/fonts
updating on theme change, 2020-07-14) really work as expected by using
not only m_hasExplicitFont, but also m_hasExplicit{Fg,Bg}Col in order to
ensure that we only update the attributes if they hadn't been explicitly
set.
This is necessary because the hack with reusing m_has{Fg,Bg}Col didn't
work under Mac where the colour wasn't used at all when they were false.
This still seems to be a problem as the behaviour is different from that
of the other ports, but fixing this in wxOSX doesn't seem to be simple,
so don't rely on this working and use separate variables instead.
Closes#18940.
Remove a lot of Mac-specific code from wxStatusBarMac in favour of using
shared wxStatusBarGeneric:
- Now that wxFRAME_EX_METAL aka NSWindowStyleMaskTexturedBackground
doesn’t affect text placement, there’s no reason for customized
DrawFieldText(). As a side effect of this removal, ellipsizing fields
is now supported.
- Remove customized DoUpdateStatusText() code that is no longer needed.
See https://github.com/wxWidgets/wxWidgets/pull/2160#pullrequestreview-563916013
