Announcement

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

  • #31
    Hi Isomorphic,

    ok, this is on the 1st point. Would this solve the issue (assuming no fetch is needed):
    • scrollToRow(rowNumber, VerticalAlignment.BOTTOM)
    • scrollToRow(rowNumber, VerticalAlignment.BOTTOM)
    Assuming that scrollToRow() is synchronous, by the time the 2nd call starts, the row is at least a bit in view and therefore the height is known. Then the 2nd call will position it correctly.
    In a real world scenario, the 1st call can issue a fetch, so the setup would be
    • Store targetRow in ListGrid subclass member variable
    • addDataArrivedHandler with 2x scrollToRow(lg.getTargetRow(), VerticalAlignment.BOTTOM)
    • Call scrollToRow(targetRow, VerticalAlignment.BOTTOM)
    • Call scrollToRow(targetRow, VerticalAlignment.BOTTOM) again
    Now either the 2nd scrollToRow() will position the then-height-known-row correctly or the two calls in the dataArrivedHandler will.

    Does this approach look good? Perhaps it can be made even better with some if (resultSet.rowIsLoaded())....
    If not, how do I wait for the redraw, as you suggest?


    Did you also see/test the 2nd point and the question on performance?

    Best regards
    Blama

    Comment


    • #32
      Hi Isomorphic,

      did you have the chance to look into this one?

      Best regards
      Blama

      Comment


      • #33
        Waiting for the redraw would currently require a timer loop, checking isDirty() or AutoTest.isGridDone(). If you prefer not to do that, you could just manually do a redraw() as soon as you've determined that the data is loaded (rowIsLoaded() and the DataArrivedHandler are the proper way to do so, as you described).

        Comment


        • #34
          Hi Isomorphic,

          OK, I will try that and report back. Did you look at the other issue and the performance question?

          Issue: Scrolling for all modes does not work if the record is already completely in the viewport. Try to scroll to any record with CENTER and then with TOP and with BOTTOM.

          Performance question: I also noticed that in the Developer Console the redraw count grows by approximately 1 per second even if I do nothing. The draw and clear counts grow by 120(!) per second. This is not the case in my application of far, nor in this sample. This also continues when I close the window. Is this an issue?

          Best regards
          Blama

          Comment


          • #35
            We'll see if we can reproduce an issue where scrollToRow() inappropriately no-ops.

            As far as a performance issue, which version of your test case does this, and what element is redrawing (trivial to determine - just enable redraws log)?

            Comment


            • #36
              Hi Isomorphic,

              all current points in this thread are about the testcase in #29, the no-op issue is also happening in that testcase, so no need create a testcase yourself.

              Regarding the redraws, the message is always:
              Code:
              10:16:47.252:TMR3:INFO:redraws:isc_BuiltInDS_MessengerTest_1_body:Scheduling redraw (70 children) (added embedded component)
              10:16:48.970:TMR5:INFO:redraws:isc_BuiltInDS_MessengerTest_1_body:Scheduling redraw (70 children) (added embedded component)
              ...
              ...
              ...
              Best regards
              Blama

              Comment


              • #37
                Hi Isomorphic,

                do you have feedback on this one?

                Best regards
                Blama

                Comment


                • #38
                  We'll get back to you on this one today as well.

                  Comment


                  • #39
                    Hi Isomorphic,

                    did you find anything out here?

                    Best regards
                    Blama

                    Comment

                    Working...
                    X