[Blama]

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

[Blama]

Hi Isomorphic,

did you have the chance to look into this one?

Best regards
Blama

[Isomorphic]

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).

[Blama]

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

[Isomorphic]

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)?

[Blama]

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:

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

[Blama]

Hi Isomorphic,

do you have feedback on this one?

Best regards
Blama

[Isomorphic]

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

[Blama]

Hi Isomorphic,

did you find anything out here?

Best regards
Blama

[Isomorphic]

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

[Blama]

Hi Isomorphic,

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

Thank you & Best regards
Blama

[Isomorphic]

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

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

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

Thank you & Best regards
Blama

[Isomorphic]

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