Announcement

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

    getRecords() returns empty List grid records in nightly build

    Working build:

    SmartClient Version: SNAPSHOT_v9.0d_2012-11-15/PowerEdition Deployment (built 2012-11-15)

    Failing builds:

    SmartClient Version: SNAPSHOT_v9.0d_2013-02-11/PowerEdition Deployment (built 2013-02-11)

    SmartClient Version: SNAPSHOT_v9.0d_2013-02-19/PowerEdition Deployment (built 2013-02-19)

    Recent nightly builds seem to have broken the following functionality.

    In a one click handler I select a record and fetch records in a List Grid based on the selection. The 4 records are fetched correctly and displayed.

    Code:
    // myId is derived from this grids selection
    // secondGrid is a global reference to another grid
    Criteria detailCrits = new Criteria();
    detailCrits.addCriteria("FK_Id", myId);
    secondGrid.filterData(detailCrits);
    Then there is a button click handler which is activated after the previous filterData() call completes:

    Code:
    	final IButton approveBtn = new IButton("Approve");
    	approveBtn.addClickHandler(new ClickHandler() {
    
    		@Override
    		public void onClick(ClickEvent event) {	
    			ListGridRecord [] currentRecords;
    			currentRecords = secondGrid.getRecords();
                    // More code based on currentRecord contents.... 
          }
    In the broken nightly builds currentRecords returns a single list grid record, i.e. array size 1, of a null record.

    In the 11-15-2012 build, currentRecords contains a list grid array of records of size 4 with the expected contents.

    Here is the response contents in the broken nightly builds:
    endRow:4,
    invalidateCache:false,
    isDSResponse:true,
    operationType:"fetch",
    queueStatus:0,
    startRow:0,
    status:0,
    totalRows:4

    Any ideas?

    #2
    This suggests not a regression per se but that your code might have been timing-dependent and the timing has now changed (possibly even due to optimizations making things faster!).

    If you call getRecords() before data has been loaded, you would expect a bad result - you should wait for DataArrived to fire before trying to access data.

    Comment


      #3
      Originally posted by Isomorphic View Post
      This suggests not a regression per se but that your code might have been timing-dependent and the timing has now changed (possibly even due to optimizations making things faster!).

      If you call getRecords() before data has been loaded, you would expect a bad result - you should wait for DataArrived to fire before trying to access data.
      I don't understand how it could be timing if I wait for the records to be populated in secondGrid, and see in the debugger that the response has completed before ever clicking the Approve button.

      Comment


        #4
        If you're waiting to see the response, then it can't be timing. How exactly you're waiting wasn't quite spelling out - by waiting for filterData(), were you waiting for DataArrived, waiting for the filterData() callback, something else?

        When you are viewing in the debugger, are you looking at a breakpoint?

        Either way, assuming you are waiting at an appropriate time.. getRecords() is not generally broken. Is there anything special about this grid - any non-default settings?

        Comment


          #5
          The first example of code
          Code:
          // myId is derived from this grids selection
          // secondGrid is a global reference to another grid
          Criteria detailCrits = new Criteria();
          detailCrits.addCriteria("FK_Id", myId);
          secondGrid.filterData(detailCrits);
          is being run in a DoubleClickHandler on firstGird.

          Double clicking on an editable cell in firstGrid allows the user to change the cell. The click first causes the secondGrid fetch, and then opens the cell for edit. When the cell edit is finished, clicking on the Approve button causes the records in secondGrid to be updated according to the edit.

          Running in the debugger on this nightly build uncovered that
          secondGrid.getRecords() was now returning a single record with contents of null.

          secondGrid has a DataSource set. The fetch caused by secondGrid.filterData() does NOT go through a DMI. I know of nothing out of the ordinary on secondGrid.

          I suppose I will add a DSCallback function to secondGrid.filterData( detailCrtis) and see if that changes the behavior.

          Can you suggest a way in the button click handler of checking that DataArrived had fired on the first filterData() call, and maybe I don't have to add the DSCallback function in the double click handler.

          Even if I wait for minutes and the Response has returned with the correct status (as seen in the debugger) from filterData(), secondGrid.getRecords() fails as I describe.

          Comment


            #6
            A definitive check for the data having loaded would be grid.getResultSet().lengthIsKnown().

            Aside from the data not having arrived yet, another possibility would be that some other code has come along and set the data to blank, via setData() or calling invalidateCache().

            Comment


              #7
              grid.getResultSet().lengthIsKnown() returns true in the Button click handler.

              I put a breakpoint at any location that does a setData() call in the code, and it never gets called, as expected.

              There is no grid.invalidateCache() call in the code.

              On the 2013-02-19 build getRecords() still returns a single record that is empty.

              The DSCallback function executed and returned in the filterData() method used in the grid click handler.

              ?????

              Comment


                #8
                We have been able to re-create a small test case that shows this problem.

                It works on 2012-11-15 and fails on the nightly 2013-02-19.

                Please use this case to confirm what we believe is your bug.

                I have attached a .zip file with the code.

                Comment


                  #9
                  We received the zip file offline (via email) and have a developer investigating

                  Thanks
                  Isomorphic Software

                  Comment


                    #10
                    A fix has been made and will be available in tonight's nightly build.

                    Comment


                      #11
                      Thanks will be looking forward to the fix.

                      Comment


                        #12
                        I have checked the 2013-02-24 build and the bug appears with getRecords() appears to be fixed in this build.

                        Comment

                        Working...
                        X