Discrepancy in cellChanged arguments and grid data between grouped and un-grouped ListGrid with a new record

[gedri]

Hi Isomorphic,

I have a ListGrid with saveLocally=true and a cellChanged handler on one of the fields (or on the grid itself for that matter).
In the cellChanged handler, I am referring to the record argument and to grid.data and I am struggling with the following discrepancy:
When the grid is not grouped, and I am adding a new record, the record argument is populated with the new record details and grid.data already includes the new record.
However, when the grid is grouped by any column, record is null and the data does not include the new record.

Here is a sample code based on the showcase in https://www.smartclient.com/smartcli...d=enterNewRows

isc.ListGrid.create({
    ID: "countryList",
    width:500, height:224, alternateRecordStyles:true,
    // use server-side dataSource so edits are retained across page transitions
    dataSource: countryDS,
    // display a subset of fields from the datasource
    fields:[
        {name:"countryName"},
        {name:"continent"},
        {name:"member_g8"},
        {name:"population"},
        {name:"independence"}
    ],
    autoFetchData: true,
    canEdit: true,
    editEvent: "click",
    listEndEditAction: "next",
[B]saveLocally : true,
cellChanged: "console.log(record); console.log(grid.data.getItem(rowNum))"[/B]
})

isc.IButton.create({
    top:250,
    title:"Edit New",
    click:"countryList.startEditingNew()"
});

Try to add a new record and watch the console when the grid is grouped and ungrouped...

Thanks

[Isomorphic]

When you report a bug, you need to report the exact version of SmartClient that you're using. So for example, "SNAPSHOT_v12.1d_2019-12-12/EVAL Development Only". You haven't even reported what release branch has the issue.

[gedri]

Sorry, I am using v120p_2019-11-27, but the problem is still reproduced with v12.0p_2019-12-12.

[Isomorphic]

The main issue here is that you've applied ListGrid.saveLocally to the grid, but that precludes also issuing server fetches against the DataSource. If you remove that property, you should find that you're getting the record passed in as expected, even when grouped.

If for some reason you want to access all the records as a ResultSet when grouped (so you can call find() for example), you can use ListGrid.originalData.

[gedri]

Hi,
Yes, I must use saveLocally because of our architecture.
My problem is that I need to identify the record for which the cellChanged event was fired.
This works fine by inspecting either the 'record' or the 'rowNum' properties passed to the event but doesn't work if the user happened to group the grid...
It strikes me as odd that some code which rightfully works when the grid is ungrouped would not work if the user happened to group the grid - something which is out of my control - unless you say I should never relay on the 'record' and 'rowNum' properties when 'saveLocally' is set (even for ungrouped grid)?

As a workaround, I assume that if 'record' is null then it must be the last record returned by originalData - but I'm not sure how reliable that w\a is (it seems to be always true in my case because I don't allow adding more that one new record at once, but I'm still looking for a more robust solution).

Thanks
Gil

[Isomorphic]

Hi,
It strikes me as odd that some code which rightfully works when the grid is ungrouped would not work if the user happened to group the grid - something which is out of my control - unless you say I should never relay on the 'record' and 'rowNum' properties when 'saveLocally' is set (even for ungrouped grid)?

As we just stated, using saveLocally when you're doing server fetches is documented as not supported. You just got lucky that it behaved as you expected when ungrouped. Future releases may cause that configuration to stop functioning altogether. You should use a supported configuration.

As a workaround, I assume that if 'record' is null then it must be the last record returned by originalData - but I'm not sure how reliable that w\a is (it seems to be always true in my case because I don't allow adding more that one new record at once, but I'm still looking for a more robust solution).

Thanks
Gil

When grouped, the originalData will remain sorted even though sorting is removed from the visible data after adding a new record. So if your grid is sorted before grouping, that assumption won't hold.

[gedri]

I understand,
So can you suggest another way I can reliably identify the record which triggered the cellChanged event in this case?
My scenario is a grid with one of the columns being a checkbox (note this is NOT a selectionAppearence=checkbox grid) which when checked by the user, some other records should be automatically unchecked as a result.
I need to know which record got checked by the user so I can determine which other records should be unchecked.

And of course I need a solution that would work with saveLocally, while the grid might be grouped by the user and the user could add new records (I hope it's not too much to ask for :-))

Thanks
Gil

[Isomorphic]

Using saveLocally with server fetches is an unsupported use of the ListGrid. It's not just cellChanged() that's unsupported in that situation, it's the complete ListGrid. So we wouldn't be able to guarantee anything works on a grid that you've configured that way. In future releases, we might just disable fetches when saveLocally is applied, and issue a warning.