Announcement

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

  • claudiobosticco
    replied
    Originally posted by claudiobosticco View Post
    PS: and we’re currently waiting for the quote to proceed with the support renewal and upgrade
    It turned out that we actually had received it *facepalm*

    Leave a comment:


  • claudiobosticco
    replied
    SmartClient Version: v13.1p_2025-06-19/Enterprise Deployment (built 2025-06-19)

    I can confirm that it's working now, thank you very much!

    Leave a comment:


  • Isomorphic
    replied
    A change to address this has been committed and ported back to 13.1. Please try the next nightly build dated June 19 or above

    Regards
    Isomorphic Software

    Leave a comment:


  • claudiobosticco
    replied
    Hi, just checking in to see if there are any updates on this issue.

    PS: and we’re currently waiting for the quote to proceed with the support renewal and upgrade

    Leave a comment:


  • claudiobosticco
    replied
    Hi, any news? Do you have an ETA for the fix?

    Leave a comment:


  • claudiobosticco
    replied
    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().

    Leave a comment:


  • Isomorphic
    replied
    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

    Leave a comment:


  • claudiobosticco
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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

    Leave a comment:


  • claudiobosticco
    replied
    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.

    Leave a comment:


  • claudiobosticco
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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

    Leave a comment:


  • claudiobosticco
    replied
    Hi, just checking in to see if anyone has had a chance to look into this. Thanks in advance

    Leave a comment:


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

    Leave a comment:


  • claudiobosticco
    replied
    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.

    Leave a comment:

Working...
X