Infralution Support

[keesp]

Hi,

I am experiencing problems with virtual tree after printing the tree structure. Apparently the printing process changes my tree so that is suddenly shows a column with edit boxes double.
I will send a test project that shows the problem.
I am currently working with the previus version of virtual tree, so not the latest.

Thanks

Kees

[Infralution]

Thanks for the sample project. There is indeed a problem with printing if you are using CellEditorMode.Always editors. The editors are created and never destroyed - which leaves them hanging around. We will fix this ASAP.

The sample project also shed some light on the other issue you've been having with incomplete painting. The problem is that you are setting the row.Expanded property from within the GetChildrenForRow method of your derived RowBinding class. This causes problems because it changes the state of the row hierarchy in a recursive/re-entrant fashion. If you want a row to be automatically expanded when it is first displayed you should set the RowChildPolicy to be AutoExpand in the RowBinding. Alternatively you can override the GetRowChildPolicy method of the tree.

I'm assuming you may have put the Asynchronous call to UpdateRowData in your overridden DataSource method to try to fix the painting issue above. I would take this out as it only adversely affects performance.

I also wondered why the scrolling performance was so bad on your sample. A little bit of profiling tracked down the source of the problem. You are creating a new editor control in your overridden GetCellData method each time it is called. Creating controls is an extremely expensive operation - if you temporarily remove this code you will see the huge performance difference. This is why the standard Virtual Tree CellEditor mechanism caches controls. Because you have bypassed this mechanism you've lost the performance benefit.

Finally doing the PrintPreview in the constructor of the form before the tree has fully completed layout seems to screw up the VirtualTreePrintDocument calculation of the number of rows to print to a page. I'm not quite sure why this is yet - but it doesn't seem like something you really should be doing anyway. If you do the printing after the form has fully loaded (via a button or menu) this is not a problem.
_________________
Infralution Support

[Infralution]

Version 2.2.1 has now been released to fix this issue.
_________________
Infralution Support

[keesp]

Hi,

Thanks for the quick response, I really feel that now I'm getting close to optimal performance! some answers to your remarks:

1: The problem is that I need to be able to set the expand of a row determined by the expand of the tree node. So there is no general policy, here. I might have a look if this is still really necessary, but basically I need to be able to check the expand property of the node, and set the row accordingly. If there is a better place to resolve this, then please let me know!

2:Yes..this was still faltering afterr a few tests. In the real application it has been removed

3: So, if I understand you correctly, it is better to create the control in the constructor and use it from there? From previous samples I got the impression that it was policy to create them in the GetCellData. I'll change that a.s.a.p

4: I know, but it was a quick way to demonstrate the problem. In the application the printing is handled through events. Diodn't feel like creating a full GUI in the test environment...

[Infralution]

[keesp]

Hi,

I have downloaded the newest version and the problem with printing has been resolved. However, when starting a print, you shortly see the misaligned edit boxes show up. It disappears almost immediately, but I am sure that this is going to lead to remarks from the users, so if this could be resolved as well at some point, that would be wonderful!

Thanks

Kees

[Infralution]

Ok we will take a look at that.
_________________
Infralution Support