No EVT_GRID_CMD_RANGE_SELECT macro in 3.1.5

12 views
Skip to first unread message

Kevin B. McCarty

unread,
Aug 13, 2021, 7:02:10 PMAug 13
to wx-u...@googlegroups.com
Hi all,

I'm taking preliminary steps in trying to upgrade our software from WX 3.1.4 to 3.1.5.

One problem I came across is that the macro EVT_GRID_CMD_RANGE_SELECT is no longer defined in include/wx/generic/grid.h as it is in 3.1.4.  According to the docs [*] it has been replaced by EVT_GRID_CMD_RANGE_SELECTED, but the backward name hasn't been kept for backwards compatibility.

Seems like this was an oversight, and there should be a macro to keep the old name, as there is for EVT_GRID_RANGE_SELECT?  As it is I'll have to use a wxCHECK_VERSION thingy during our transition.

Additionally -- We're explicitly using --disable-compat30 in our ./configure flags to make sure that we don't keep using old cruft, but the old name EVT_GRID_RANGE_SELECT itself is now guarded by a macro for that, so our builds under 3.1.5 don't see that either.  Seems a little abrupt to move the old spelling from "always available and the only option" status to "deprecated and hidden by --disable-compat30" status in only a single point release.  Though maybe there is good reason for it...


Regarding the above page, note that the description of  EVT_GRID_CMD_RANGE_SELECTED on that page erroneously says that the old name of the macro was EVT_GRID_RANGE_SELECT rather than EVT_GRID_CMD_RANGE_SELECT.

Thanks for your attention,

--
Kevin B. McCarty
<kmcc...@gmail.com>

Vadim Zeitlin

unread,
Aug 13, 2021, 7:22:14 PMAug 13
to wx-u...@googlegroups.com
On Fri, 13 Aug 2021 16:01:56 -0700 Kevin B. McCarty wrote:

KBM> One problem I came across is that the macro EVT_GRID_CMD_RANGE_SELECT is no
KBM> longer defined in include/wx/generic/grid.h as it is in 3.1.4. According
KBM> to the docs [*] it has been replaced by EVT_GRID_CMD_RANGE_SELECTED, but
KBM> the backward name hasn't been kept for backwards compatibility.
KBM>
KBM> Seems like this was an oversight,

Yes, indeed, thanks for noticing this. The backwards-compatible synonym
for this macro was forgotten in 415f080c80 (Split wxGrid RANGE_SELECT event
into SELECTING and SELECTED, 2020-07-27) and I've just added it now in
7b5783e4f8 (Restore accidentally removed EVT_GRID_CMD_RANGE_SELECT macro,
2021-08-14).

KBM> Additionally -- We're explicitly using --disable-compat30 in our
KBM> ./configure flags to make sure that we don't keep using old cruft, but the
KBM> old name EVT_GRID_RANGE_SELECT itself is now guarded by a macro for that,
KBM> so our builds under 3.1.5 don't see that either. Seems a little abrupt to
KBM> move the old spelling from "always available and the only option" status to
KBM> "deprecated and hidden by --disable-compat30" status in only a single point
KBM> release. Though maybe there is good reason for it...

If you use --disable-compat30, this indeed means that you don't want to
use any APIs that have better replacements now, so this makes sense to me.
The only alternative would be to always define, i.e. not deprecate it at
all, but then we'd have to keep it forever (well, until 3.6.0, which is
about the same thing).

OTOH I guess there is no real harm in keeping it and I do see several
packages use EVT_GRID_RANGE_SELECT at

https://codesearch.debian.net/search?q=EVT_GRID_RANGE_SELECT&literal=1

But even more packages use EVT_GRID_CELL_CHANGE, which is disabled when 2.8
compatibility is turned off. So by this logic we shouldn't actually
deprecate it neither.

So, finally, I'm probably going to remove the compatibility checks around
the definitions of these macros, if there are no objections, as it really
doesn't cost us anything to keep them and it would save some work for
people upgrading to 3.2.


KBM> Regarding the above page, note that the description of
KBM> EVT_GRID_CMD_RANGE_SELECTED on that page erroneously says that the old name
KBM> of the macro was EVT_GRID_RANGE_SELECT rather than
KBM> EVT_GRID_CMD_RANGE_SELECT.

I've fixed this too in the commit above, thanks for noticing this too!
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

Kevin McCarty

unread,
Aug 16, 2021, 12:10:50 PMAug 16
to wx-users
On Friday, August 13, 2021 at 4:22:14 PM UTC-7 Vadim Zeitlin wrote:
Yes, indeed, thanks for noticing this. The backwards-compatible synonym
for this macro was forgotten in 415f080c80 (Split wxGrid RANGE_SELECT event
into SELECTING and SELECTED, 2020-07-27) and I've just added it now in
7b5783e4f8 (Restore accidentally removed EVT_GRID_CMD_RANGE_SELECT macro,
2021-08-14).

Many thanks for fixing this, Vadim!
 
If you use --disable-compat30, this indeed means that you don't want to
use any APIs that have better replacements now, so this makes sense to me.
The only alternative would be to always define, i.e. not deprecate it at
all, but then we'd have to keep it forever (well, until 3.6.0, which is
about the same thing).

Here I guess there is some impedance mismatch between the eventual plan for how client code currently at 3.0.x might upgrade to the eventual 3.2.0; versus how client code that is tracking the 3.1 branch can easily upgrade from 3.1.x to 3.1.(x+1).

I agree with you that, since EVT_GRID_RANGE_SELECT macro (and its CMD friend) were renamed in the course of the 3.1 dev branch, it makes sense that application developers who are building their code against 3.2.0 (in the future) with --disable-compat30 should get a compile error wherever they have used the old name, so that they know to upgrade.

But since it is so long between wx major production branches (2.8 -> 3.0 -> 3.2), many of us out there are following the 3.1.x releases, upgrading one (or at most a few) point releases at a time.  So here it seems to me that what --disable-compat30 should do, is a little less clear.  I wouldn't want my own employer to abandon our use of --disable-compat30, since it does prevent us from falling into usage of old code that has long-since been deprecated.

I wonder if it could be feasible to deprecate a symbol in a 3.1.x release, but then do not hide it with --disable-compat30 until the following 3.1.(x+1) release?  (Or if it was the last in the 3.1.x line, then hide it in 3.2.0)

In order that you wouldn't have to remember to keep track of such symbols for two point releases in a row, one could envision a new macro named something like wxDEPRECATED_AFTER() or something like that.  If we assume that this already existed, then in 3.1.5 the EVT_GRID_(CMD_)RANGE_SELECT macro old names could have been wrapped in a #if wxDEPRECATED_AFTER(3,1,5) ... #endif, which would keep it visible for the 3.1.5 release even with --disable-compat30, but make it invisible for the 3.1.6 release [since 3.1.6 > 3.1.5] when --disable-compat30 was given.

I'm afraid I wouldn't have time to look into this myself, so I totally understand if you aren't interested in taking this sketch of an idea and implementing it in reality :-)

Thanks for listening, in any case!
Kevin

Vadim Zeitlin

unread,
Aug 16, 2021, 12:35:32 PMAug 16
to wx-u...@googlegroups.com
On Mon, 16 Aug 2021 09:10:49 -0700 (PDT) Kevin McCarty wrote:

KM> I wonder if it could be feasible to deprecate a symbol in a 3.1.x release,
KM> but then do not hide it with --disable-compat30 until the following
KM> 3.1.(x+1) release? (Or if it was the last in the 3.1.x line, then hide it
KM> in 3.2.0)

I think it's a good idea, thanks, but we're hopefully close to the end of
3.1.x series, with 3.1.6 supposed to be the final release, and so we
shouldn't hopefully need this in the near future. And to solve the problem
with these macros, I'd rather just apply

https://github.com/wxWidgets/wxWidgets/pull/2463

and not deprecate them at all.

But, again, I agree that this makes sense and we should probably do
something like this for 3.3.x.

Regards,
Reply all
Reply to author
Forward
0 new messages