Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    formatCellValue calls after startEditingNew

    SmartClient Version: v13.1p_2025-03-21/AllModules Development Only (built 2025-03-21)

    Hello, I've got a problem in my application which I managed to replicate in the showcase, please try this test case:

    Code:
    isc.ListGrid.create({
        ID: "countryList",
        width: 700, height: 224,
        showFilterEditor: true,
        initialSort: [
            {
                property: "countryName",
                direction: "ascending"
            }
        ],
        dataSource: worldDS,
        fields: [
            {name: "countryName"},
            {name: "continent"},
            {
                name: "government",
                formatCellValue: function (value, record, rowNum, colNum, grid) {
                    isc.logEcho(record, "formatCellValue " + rowNum)
                }
            },
            {name: "area"},
            {name: "gdp"},
            {name: "independence", width: 100}
        ]
    })
    then if you run countryList.startEditingNew() you'll see a WARN:

    Code:
    *15:52:44.505:WARN:gridEdit:countryList:startEditing() passed bad cell coordinates:1000,0, can't edit
        ListGrid.startEditing(_1=>1000, _2=>0, _3=>undef, _4=>undef, _5=>undef) on[ListGrid ID:countryList] @ ISC_Grids.js:2264:97
        ListGrid.startEditingNew(_1=>undef, _2=>undef) on[ListGrid ID:countryList] @ ISC_Grids.js:2456:6
        null.<anonymous>(<no args: exited>) @ [no file]:1:13
    and data will be fetched (I wasn't expecting this).

    Instead if you run countryList.startEditingNew({continent:"Asia"}) you'll see also many calls to formatCellValue with record === null (for rowNums==0 to 8, and from 992 to 999, for rowNum == 1000, you'll see a record with the continent value).

    is this a bug, or has there been some change in behaviour? Currently my code does not expect record to be null, and even the fetch seems unexpected

    #2
    also note that in my actual use case I've got autoSaveEdits:false

    Comment


      #3
      Hello, any news about this issue?

      Out of curiosity, I've tried the test case in 14.1 and 15.0 also, and I see the same behaviour.
      Last edited by claudiobosticco; 28 Mar 2025, 02:43.

      Comment


        #4
        Hi Claudio
        It would help us to understand what you're trying to do here. Usually startEditingNew() is used to edit a new record at the end of a grid's data set and it wouldn't be expected to call it on an empty data bound grid.

        Are you using "saveLocally" and using the DataSource as just a schema rather than intending to save edits through standard DataSource add/update operations? We can certainly look into what's going on with the default behavior you're describing but what are you actually trying to achieve here?

        Thanks

        Comment


          #5
          Hello, in my application, the grid is empty because no records match the criteria. In fact, grid.data is:

          Code:
          ResultSet{autoFetchRowCount: undef,
          dbcFields: Array[16],
          dbcCacheOrdinal: 3,
          fetchDelay: 1,
          operation: Obj{ID:fetchEventiSquadraWithTipologia},
          filter: Obj,
          context: Obj,
          componentId: "gestPlanningTeamManagerEventEditPadreSqu..."[48],
          ID: "isc_ResultSet_1",
          fetchOperation: "fetchEventiSquadraWithTipologia",
          fetch_OpConfig: Obj{ID:fetchEventiSquadraWithTipologia},
          dataSource: [DataSource ID:JAS_CALENDARIO_EVENTI_SQUADRA],
          fetchMode: "paged",
          criteria: Obj,
          localData: Array[0],
          totalRows: 0,
          lastRangeStart: 0,
          lastRangeEnd: 25}
          However, I couldn't replicate this issue in the showcase with an empty ResultSet.

          Other than that, the observed behaviour is exactly the same. I've also discovered that the problem occurs only when the grid has an initialSort, both in my application and in the test case.

          Comment


            #6
            Hello, just checking if you're able to look into this issue with the additional details of post #5

            Comment


              #7
              Hi, just checking in to see if anyone has had a chance to look into this. Thanks in advance

              Comment


                #8
                Hi Claudio,

                The correct behavior when calling 'startEditingNew()' on a data bound ListGrid that has never fetched data (so has its data set to an empty array - the default, and doesn't yet know the size of its full dataset) is arguably a little ambiguous and as you observed in your original test case this is currently not behaving well.
                We are reviewing how best to handle a startEditingNew() call on a ListGrid that has never fetched data.

                However your description in post #5 indicates that this doesn't really reflect the scenario in your usage. You aren't dealing with a grid that has never fetched data, you're dealing with a grid that has successfully performed a fetch and found no matching results (localData.length is zero) which should be handled, and appears to work in our testing.

                To get through this issue we really need to see the problem as you're seeing it in your application. What is special about this ListGrid / what is the order of the API calls you're making that's getting into this bad state?
                As always if you can show us a way to reproduce the problem that will be ideal. If it's not possible to show a standalone test case, if you could at least show us the relevant snippets from your application - your ListGrid definition, your code that issues the fetch, your code that kicks off the startEditingNew() and anything else that seems like it might have bearing on your usage this may help us get to the bottom of this.

                Thanks and Regards
                Isomorphic Software

                Comment


                  #9
                  Hi, ok, I was hoping that the fact that the initialSort on the grid is necessary to trigger the issue (both in the test case from the first post and in my app) could shed some light on it.

                  If not, I’ll try to reproduce the issue again, or at least find some other useful clues.

                  Comment


                    #10
                    Hi, after further analysis of my use case, I need to correct myself - and I apologize for not realizing this earlier.

                    The case where the grid has been fetched (as in post #5), with the latest available build (SmartClient Version: v13.1p_2025-05-25/Enterprise Deployment (built 2025-05-25)),
                    seems to be resolved - I no longer see the issue.

                    However, I also realized that my main use case is actually the one where the grid has never been fetched (as in the test case from post #1).
                    This is because its criteria are based on a foreign key that I don’t have yet (since the parent record hasn’t been saved yet).
                    Note that in this case, initialSort is necessary to trigger the problem.

                    Comment


                      #11
                      Hi Claudio
                      We have been doing internal analysis and we have a good understanding of what's happening and why the initialSort is making things behave differently.

                      However, in order to make sure we do the "right fix" here, it would be very helpful for us to have a clear understanding of your use case as currently we're not completely clear on what the expected behavior is.

                      From your description:
                      • You have a grid (ListGrid presumably, rather than TreeGrid?) that is bound to a dataSource.
                      • The grid has never fetched data.
                      • You call startEditingNew, allowing the user to edit a new record.
                      • When the user is done with the edit, what happens?
                        • You mention that you have autoSaveEdits:false, so initially the edit will just be stashed in the editValues for the grid. Are you then calling saveData() yourself?
                        • Is the intention for that saveData() call to add the record to the dataSource or are you intending to store it to local data and work with it directly?
                      • Then at a later stage you will call fetchData() on the same grid
                        • Is the fetchData invoked in response to the user successfully saving their edited record?
                      • When you call fetchData(), the grid will populate itself with multiple records. If you saved the user-edited record to the server, this record might or might not be part of that data-set depending on the criteria, presumably
                      Can you flesh this out a little? It might be helpful to describe from a user-perspective what the actual interaction is

                      Thanks for your help

                      Isomorphic Software

                      Comment


                        #12
                        Hi, in my code I have the following setup:
                        - A ListGrid bound to a DataSource, with autoSaveEdits: false.
                        - The grid has not fetched data, because the criteria depends on a foreign key referencing a parent record that doesn’t exist yet.
                        - The user can create one or more records (via startEditingNew).
                        - Then, the user saves the newly created records.
                        - My code (which is rather old and definitely could be improved) doesn't use saveAllEdits; instead, I use a fully custom method to send the records (retrieved via getEditedRecord()) to the server for saving.
                        - In the callback, where I get the foreign key I need for the criteria, I call grid.discardAllEdits(), then grid.setCriteria(), and finally grid.refreshData().

                        Let me know if you need any more details.

                        Comment


                          #13
                          Hi Claudio
                          One more question - does the user continue to edit the records in the grid after the fetch, and if so how are you saving those to the server?

                          Thanks

                          Comment


                            #14
                            Hi, yes the user can continue editing the grid afterwards as well, and the grid always has autoSaveEdits: false.
                            For saving, I still use my custom method, and in the callback I call grid.discardAllEdits() and grid.refreshData().

                            Comment

                            Working...
                            X