[Isomorphic]

The "jump back" issue you're pointing out in your last post is different than the previous issue in that it only affects the first page, and is unavoidable unless we limited the amount you can scroll before the delayed redraw fires.

We can't align node root-1-12 in your sample with where you scrolled it when the redraw runs because there aren't enough rows above it in the Tree.

[SimonF]

Thanks for mentioning the datasource, i haven't seen this case an it has been fixed in the datasource.

I also thought, that the "jump back" while scrolling up is different. I have tested this again with a node without 3 lines, and this also happens with only 1 row-nodes.
I don't know if i understand you completely. If I'm using "fixedRecordHeights: false", there will be always this scrolling-to top issue? Maybe also because of the VirtualScrolling?
Admitting, that there are borders which cannot be passed, I think there is no chance in fixing this.

There are many components and methods that are very well documented, but the paged treegrid seems not to be documented as it should be. Therefore I awaiting the docs so much. I'm keep posting issues regarding the treegrid since end of march and by now it seems I doesn't have understand in which situations I have to set the childCount, in which situations i could set it, and in what situations I cannot set it.

If the node is a leaf => no childCount
If the node is a open folder (isOpen:true) without children => Invalid state, but now fixed with warning
If the node is a open folder (isOpen:true) with children => childCount must be set
If the node is a closed folder => childCount can be set
If the node is a closed folder with children => childCount can be set

I think i don't understand why setting childCount without sending children is ok for a closed folder, but results into a warning when using it with an open folder.
By now I have understood, that i could return nodes with "isOpen:true" which does fire a immediately fetch for this node. I have thought, that if I set "canReturnOpenFolders" that I also can set isOpen to true and set the childCount, so the treegrid already knows how many childs there would be. If the node will be visible (or near the viewport) this informations of the childCount could be used for the request or for the scollbar that there is no need to resize this later on after the first request.

Is there any epected release date for the documentation, where I can read more about the childCount and the other possibilities?
We have multiple usecases for the paged treegrid and I really want to finish this implementation with some working examples ;-)

Best

[Isomorphic]

Thanks for mentioning the datasource, i haven't seen this case an it has been fixed in the datasource.

I also thought, that the "jump back" while scrolling up is different. I have tested this again with a node without 3 lines, and this also happens with only 1 row-nodes.
I don't know if i understand you completely. If I'm using "fixedRecordHeights: false", there will be always this scrolling-to top issue? Maybe also because of the VirtualScrolling?
Admitting, that there are borders which cannot be passed, I think there is no chance in fixing this.

There are many components and methods that are very well documented, but the paged treegrid seems not to be documented as it should be. Therefore I awaiting the docs so much. I'm keep posting issues regarding the treegrid since end of march and by now it seems I doesn't have understand in which situations I have to set the childCount, in which situations i could set it, and in what situations I cannot set it.

If the node is a leaf => no childCount
If the node is a open folder (isOpen:true) without children => Invalid state, but now fixed with warning
If the node is a open folder (isOpen:true) with children => childCount must be set
If the node is a closed folder => childCount can be set
If the node is a closed folder with children => childCount can be set

I think i don't understand why setting childCount without sending children is ok for a closed folder, but results into a warning when using it with an open folder.

When a node is open, it should have a consistent child configuration, which means a valid child count and at least one child included if the child count is > 0. If the folder is closed, the Framework doesn't need to know anything about the children, so sending any child configuration is optional.

By now I have understood, that i could return nodes with "isOpen:true" which does fire a immediately fetch for this node. I have thought, that if I set "canReturnOpenFolders" that I also can set isOpen to true and set the childCount, so the treegrid already knows how many childs there would be. If the node will be visible (or near the viewport) this informations of the childCount could be used for the request or for the scollbar that there is no need to resize this later on after the first request.

If we allowed not sending any children along with an opened node, that would require an immediate return call to the server to fetch the children, which is inefficient and would greatly complicate logic that tries to work with the tree model (both framework logic and application logic), so we prohibit it. (Violations are warned, and an immediate fetch issued, as mentioned.) Not also that, even if we allowed a childCount without children, it wouldn't solve the scrollbar issue, because we still wouldn't know how many children those children had (grandchildren node count).

Is there any epected release date for the documentation, where I can read more about the childCount and the other possibilities?
We have multiple usecases for the paged treegrid and I really want to finish this implementation with some working examples ;-)

Best

We give highest priority to support requests, and you've been filing many of them recently. The doc updates are lower priority, but we've already communicated the main rules:
- for an opened node, you must return a child count and at least one child (if child count is > 0)
- for a leaf, there must be no children and no child count (or child count of 0)

[Isomorphic]

We've addressed the "jumping" issue you reported when the grid is positioned near the first page of rows. The fix will be ported back to SC 10.0p and should be available in the nightly builds marked 5-15-2015.

[SimonF]

thanks for the explanations.
"Jumping"-issue is now fixed.
Tested with the latest nightly (SmartClient_v100p_2015-05-15_Pro).
Thank you very much, i think this was the last open issue in this thread.
If I find something new (hopefully not) I'll open a new thread ;-)

Best