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


                    • #40
                      On this:
                      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?
                      Initially we were having difficulty reproducing this but are now seeing it. We haven't pinned down a cause yet but will follow up when we have more information

                      Regards
                      Isomorphic Software

                      Comment


                      • #41
                        Hi Isomorphic,

                        great to hear this. Can you also have a look at the no-op from scrollToRow()?

                        Thank you & Best regards
                        Blama

                        Comment


                        • #42
                          The issue related to scrollToRow() is already fixed in current builds.

                          Regards
                          Isomorphic Software

                          Comment


                          • #43
                            Hi Isomorphic,

                            scrollToRow() is working fine for me using v11.1p_2018-02-21.

                            Thank you & Best regards
                            Blama

                            Comment


                            • #44
                              We've made a change to the 6.1p and 12.0d branches to avoid the huge numbers of redraws / clears/draws referenced in this thread. Please try the next nightly build (dated Feb 28 or above) to pick up the change

                              Regards
                              Isomorphic Software

                              Comment

                              Working...
                              X