View previous topic :: View next topic |
Author |
Message |
keesp Guest
|
Posted: Tue Oct 25, 2005 11:41 am Post subject: misalignment of columns after printing |
|
|
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 |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Oct 26, 2005 12:25 am Post subject: |
|
|
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 |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Oct 26, 2005 3:24 am Post subject: |
|
|
Version 2.2.1 has now been released to fix this issue. _________________ Infralution Support |
|
Back to top |
|
|
keesp Guest
|
Posted: Wed Oct 26, 2005 6:27 am Post subject: various issues... |
|
|
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... |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Oct 26, 2005 6:40 am Post subject: Re: various issues... |
|
|
keesp wrote: | Hi,
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!
|
You can set the ChildPolicy on a row by row basis by overriding the GetRowChildPolicy method of VirtualTree. The latest release now also lets you override the corresponding GetChildPolicy method on the RowBinding (this wasn't virtual before so you couldn't override it).
Quote: | 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 |
You can create the editor and associated control in the constructor - but personally I would use the Virtual Tree Editor (from the designer) to add cell editors because you can see all of the properties. Another small performance tip when using Universal Edit Box (or TextBox) as an editor is to not set the AutoSize property to true if the CellEditor.UseCellHeight property is set to true. This is because it causes an extra layout event to occur and some flashing. _________________ Infralution Support |
|
Back to top |
|
|
keesp Guest
|
Posted: Thu Oct 27, 2005 11:26 am Post subject: continued... |
|
|
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 |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Thu Oct 27, 2005 12:37 pm Post subject: |
|
|
Ok we will take a look at that. _________________ Infralution Support |
|
Back to top |
|
|
|