Skip to main content
sarathkumr268295
sarathkumr268295
December 18, 2024
Question

Getting start index should not be greater than total count

  • December 18, 2024
  • 6 replies
  • 1 view

We are getting the expression evaluation error that start index must not be greater than total count. We got the scenario from the user when this issue is occuring. For example, there are 25 tasks in a grid. In 1st page, we will show 1 to 10 tasks, 2nd page with 11 to 20 and last page will have 5 tasks. This count is same for 2 users. Both users open the same page and 1st user completes lets say 5 tasks. So for the 1st user, the task count gets reduced but for the other user, the count will not get reduced since he hasnt performed any action in the page. Now when he clicks on the last page icon in the grid, the following error pops up. Any suggestion to solve this issue?? The tasks are being queried from task report.

6 replies

stefanhelzle0001
stefanhelzle0001
December 18, 2024

You will have to reset the startIndex when doing any actions that could potentially reduce the number of items. Or you add a validation on the startIndex that resets it in such a case.

    sarathkumr268295
    sarathkumr268295Author
    December 19, 2024

    Hi Stefan,

    Any suggestion would be helpful on how to reset it because the paginginfo is calculated automatically by the grid using fv!paginginfo which is being as paginginfo parameter to the query. The icons are also provided by the grid. So I am not able to understand how to reset it.

    mikes0011
    mikes0011
    Brainy
    December 20, 2024

    Then you'll need to post your code snippet showing how you construct your grid as well as how you're doing your task report query.

    If you're just talking about the corner case described where 2 users are picking tasks from the same queue and the "go to last page" functionality causes an error for user B when user A has accepted the one task needed to make the page count drop, then I think you might just be in a situation where you need to do a periodic data refresh on the queried data (like set up a auto refresh with value 0.5 for instance).  Otherwise I'm not sure you'll be able to elminate this case completely, but also, how often will this realistically actually happen to users in the wild, when they're not looking to demonstrate an error?

    Terms & ConditionsAccessibility statement