wxSmith/wxGrid incompatibility with wx3.1 wxEVT_GRID_CELL_CHANGE(D)

[cacb]

I have discovered an incompatibility with wxWidgets 3.1 when generating wxGrid controls and using wxEVT_GRID_CELL_CHANGE event. Apparently, this event ID does not exist anymore, I think it should be wxEVT_GRID_CELL_CHANGED  (notice the 'D' at the end)

If it matters, I am using C::B rev 10376 on Windows

[oBFusCATed]

Can you try the latest night build and report if the problem is still happening?

[cacb]

Can you try the latest night build and report if the problem is still happening?

I have just tried with rev 10922     "The 20 November 2016 build (10922)" and the problem is still the same. It looks like this ID has been discouraged for quite some time (deprecated?) and in wx3.1 it is gone. It is a problem when wxSmith still uses the now non-existent ID.

As a temporary work around I had to add in my code
#define wxEVT_GRID_CELL_CHANGE wxEVT_GRID_CELL_CHANGED

So, yes it is still a problem.

[stahta01]

From wxWidgets master branch; file grid.h.

Code

// we used to have a single wxEVT_GRID_CELL_CHANGE event but it was split into
// wxEVT_GRID_CELL_CHANGING and CHANGED ones in wx 2.9.0, however the CHANGED
// is basically the same as the old CHANGE event so we keep the name for
// compatibility
#if WXWIN_COMPATIBILITY_2_8
    #define wxEVT_GRID_CELL_CHANGE wxEVT_GRID_CELL_CHANGED

    #define EVT_GRID_CMD_CELL_CHANGE EVT_GRID_CMD_CELL_CHANGED
    #define EVT_GRID_CELL_CHANGE EVT_GRID_CELL_CHANGED
#endif // WXWIN_COMPATIBILITY_2_8

Tim S.

[oBFusCATed]

Someone should teach wxsmith to generate the event with a condition - the old event for 2.8 and the new event for 3.x. Patches welcome. wxsgrid.cpp should be the starting point for the patch generation.

[Miguel Gimenez]

I have added a target version setting in Editor->wxSmith and version information to selected events so they are discarded if not available in that version. This includes the events from wxGrid, wxDirCtrl and wxComboBox.

CAVEATS: Probably the target version setting should be project dependent. Also, if you change the target version CB must be restarted in order to activate the changes. I hope this patch serves a first approach.

Not included are:
  wxEVT_SCROLL_ENDSCROLL, changed to wxEVT_SCROLL_CHANGED in 2.8.0
  wxEVT_STC_AUTOCOMP_COMPLETED, new in 3.1.1
  wxEVT_AUI_PANE_ACTIVATED, new in 2.9.4
  wxEVT_RIBBONGALLERY_CLICKED and wxEVT_RIBBONBAR_TAB_LEFT_DCLICK, new in 2.9.2
  wxEVT_DATAVIEW_CACHE_HINT, new in 2.9.1

[oBFusCATed]

I don't like the idea of storing the version in the settings.
Can't you just generate the correct code with ifdefs for both versions?

[Miguel Gimenez]

If you use #ifdefs you will see only events valid for the wxWidgets version used when compiling CB. In my case I am using CB compiled with wxWidgets 2.8.12 but I am developing using wxWidgets 3.1.0.

A possibility would be showing all known events and letting the compiler bark if you assign a handler to an invalid event.

[cacb]

I think wxSmith should primarily target wxWidgets 3.x these days, and issue events corresponding to that, i.e. use the current wxEVT_GRID_CELL_CHANGED . Then when compiling against wx2.8 there could simply be a #define somewhere for backwards compatibility.

Perhaps something like this (when compiling an application, not when compiling C::B)


#if wxCHECK_VERSION(2, 8, 0)
#define wxEVT_GRID_CELL_CHANGED  wxEVT_GRID_CELL_CHANGE
#endif


I.e. it would be the responsibility of the application developer to stay compatible with outdated wxWidgets versions. The responsibility of wxSmith is then to stay up to date with latest stable release of wxWidgets.

I think this is cleaner.

[stahta01]

I think wxSmith should primarily target wxWidgets 3.x these days, and issue events corresponding to that, i.e. use the current wxEVT_GRID_CELL_CHANGED . Then when compiling against wx2.8 there could simply be a #define somewhere for backwards compatibility.

Perhaps something like this (when compiling an application, not when compiling C::B)


#if wxCHECK_VERSION(2, 8, 0)
#define wxEVT_GRID_CELL_CHANGED  wxEVT_GRID_CELL_CHANGE
#endif


I.e. it would be the responsibility of the application developer to stay compatible with outdated wxWidgets versions. The responsibility of wxSmith is then to stay up to date with latest stable release of wxWidgets.

I think this is cleaner.

This is the solution that I think is easiest to create and maintain; just target the latest production wxWidgets (3.0.2) for code generation with an header file included for the prior production version(s).

Tim S.

 

[oBFusCATed]

If you use #ifdefs you will see only events valid for the wxWidgets version used when compiling CB. In my case I am using CB compiled with wxWidgets 2.8.12 but I am developing using wxWidgets 3.1.0.

I'm talking about ifdefs in the generated code by wxsmith, not in wxsmith's code itself.
At a later time we can have a setting that changes the minimal version code is generated for.

[oBFusCATed]

For the record wx3.1.0 is not a good version to use until wx-devs start saying that it is the stable version.
Until then the latest stable and supported by wxsmith version is wx 3.0.x!
And features that are 3.1 only should be ifdef-ed or ignored.

[Miguel Gimenez]

Ok, here is a new patch adding only the missing events