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

  • Blama
    Hi mathias,

    did not see it or perhaps deleted it accidentally. Please try again

    Best regards

    Leave a comment:

  • mathias
    Hey Blama, tried to reach you at your @gmx address. Would like to talk, is it possible to reach you somewhere?

    Leave a comment:

  • Blama
    Hi Isomorphic,

    actually I think you don't need to implement the feature mentioned in order to fix this for all possible cases.
    It should be enough to be able to define how the DB is going to return nulls (FIRST/LAST) in case of sorting ASC/DESC in the Browser with some static method before actually loading the application.
    But unfortunately both this and the mentioned feature wouldn't even solve all cases, see below.

    This problem might also relate to this thread which is about CI/CS sort where there is basically the same difference.
    I think much of the confusion I had when scrolling in the sample is related to your sentence in the linked post:
    Originally posted by Isomorphic View Post
    Yes, we always use a client-side sort whenever we get a complete cache.
    Without this extra clientside-sort, order would not change until the user manually clicks a column header.
    If in the case of a complete cache here the server and client sorting don't work the same, I think this is OK - I heard no complains so far. But resorting while scrolling is confusing IMHO.

    Best regards

    Leave a comment:

  • 12.0p: ListGrid null value sorting bug depending on ResultSet partially or loaded

    Hi Isomorphic,

    please see this modified sample (v12.0p_2020-01-07). You'll notice that:
    • Rows with empty unit field are at top
    • Total rows are 235
    • Scrolling down issues requests for next 75 rows a few times as expected
    • While this happens sort does not change (as expected)
    • When the last page is requested (rows 225 - 235), a resort happens and rows with null in the unit field are moved to bottom (unexpected)
    • If you enable dataFetchMode: "local", the second sorting with nulls last is active directly from the start, while the data returned are again in the order where the rows with data in the column are last (unexpected)
    Tested on Chromium 79 and FF 26.

    I'm not sure which behavior is correct here, but the sorting should definitely not change while scrolling.
    As it is not clear that all DB will behave the same by default w.r.t. NULLS FIRST/LAST this somehow relates to this old feature suggestion of mine.

        ID: "supplyItemList",
        dataSource: "supplyItem",
        // dataFetchMode: "local",
        sortField: "units",
        canEdit: true,
        width: "100%",
        height: 550,
        autoFetchData: true,
        initialCriteria: {
            _constructor: "AdvancedCriteria",
            operator: "or",
            criteria: [{
                    fieldName: "category",
                    operator: "equals",
                    value: "Computer Consumables"
                    fieldName: "category",
                    operator: "equals",
                    value: "Canteen and Washroom Products"
    Best regards,