Infralution Support Forum Index Infralution Support
Support groups for Infralution products
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Implementation Tipps

 
Post new topic   Reply to topic    Infralution Support Forum Index -> Virtual Tree Support
View previous topic :: View next topic  
Author Message
flc.net



Joined: 21 Jun 2005
Posts: 89
Location: Switzerland

PostPosted: Mon Aug 29, 2005 2:06 pm    Post subject: Implementation Tipps Reply with quote

Hello Support

I have a few questions. Please look again at my Image:


Only the Level 3 have a bool Value bound to the CheckBox.
The CheckBoxes on Level 1 and Level 2 are just for Information:
When all Level 3 Objects are checked, then the Level 2 CheckBox is also Checked.
When none of Level 3 Objects are checked, then Level 2 is also unchecked.
When some of Level 3 Objects are checked, then Level 2 have the CheckState "Intermediate".

The Level 2 can also be used to set the same State on all Level 3 Child Objects.

My Questions:
1. Does the DataTable for Level 2 need a Dummy Column that can store the Value of the CheckBox? Or is this not neccessary?

2. When the User changes the State on the Level 2 CheckBox, do I set the Values of Level 3 in the DataSet Row or with the SetCellValue Method?

Thanks for your Help
Giuseppe
Back to top
View user's profile Send private message
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Mon Aug 29, 2005 10:34 pm    Post subject: Reply with quote

Some answers:

1. You could use a dummy column - you could also handle the GetCellData event for this column and calculate the value on the fly.

2. You would probably handle the SetCellValue event for level 2 rows and the prefix column and set DataSet Row bool value for all child (level 3) rows.

Don't forget when handling the GetCellValue and SetCellValue events/methods to call the RowBinding.SetCellValue and RowBinding.GetCellValue methods to implement the default behaviour for other columns/rows.
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
flc.net



Joined: 21 Jun 2005
Posts: 89
Location: Switzerland

PostPosted: Tue Aug 30, 2005 10:12 am    Post subject: Reply with quote

Ok, it's was a hard fight, but now it works. Smile I had problems to understand the real functionality of Set/GetCellValue.

Just wondering: I noticed that when I change the Value of one Cell, then VirtualTree performs a GetCellData for each Visible Cell? Why?

Thanks again for your very great Support!
Giuseppe
Back to top
View user's profile Send private message
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Tue Aug 30, 2005 10:24 am    Post subject: Reply with quote

If you are using DataSet binding then SetCellValue changes the underling DataRow which in turn raises a ListChanged event to let subscribers know that the data has changed. VirtualTree responds to this by updating the displayed data.
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
flc.net



Joined: 21 Jun 2005
Posts: 89
Location: Switzerland

PostPosted: Fri Sep 16, 2005 2:30 pm    Post subject: Reply with quote

Infralution wrote:
If you are using DataSet binding then SetCellValue changes the underling DataRow which in turn raises a ListChanged event to let subscribers know that the data has changed. VirtualTree responds to this by updating the displayed data.


Hello Support

It's there a possibility to tell VT that it's not neccessary to update the displayed data?
Because I make a lot of changes programmatically in the DataSet the get CellData will be fired a lot of time and my App slow down.

Thanks and Best Regards
Giuseppe
Back to top
View user's profile Send private message
Guest






PostPosted: Fri Sep 16, 2005 11:53 pm    Post subject: Reply with quote

Call VirtualTree.SuspendLayout before making a series of changes and VirtualTree.ResumeLayout when you've completed the changes.
Back to top
flc.net



Joined: 21 Jun 2005
Posts: 89
Location: Switzerland

PostPosted: Mon Sep 19, 2005 6:54 am    Post subject: Reply with quote

Anonymous wrote:
Call VirtualTree.SuspendLayout before making a series of changes and VirtualTree.ResumeLayout when you've completed the changes.


Hello

That doesn't work. The problem is that GetCellData will be called to many times. It's not a Drawing/Display problem.

Thanks
Giuseppe
Back to top
View user's profile Send private message
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Mon Sep 19, 2005 11:19 pm    Post subject: Reply with quote

The calls to GetCellData are done (indirectly) from within OnLayout as Virtual Tree works out what visual elements need to be displayed - so SuspendLayout should stop these occuring. Are you sure this is not working?
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
flc.net



Joined: 21 Jun 2005
Posts: 89
Location: Switzerland

PostPosted: Tue Sep 20, 2005 9:48 am    Post subject: Reply with quote

Infralution wrote:
The calls to GetCellData are done (indirectly) from within OnLayout as Virtual Tree works out what visual elements need to be displayed - so SuspendLayout should stop these occuring. Are you sure this is not working?


Hello Support

I sent you a Sample App. I have a similar behaviour in my Real App:

- Run the App (Form2) --> GetCellData is invoked about 800 times. It strange, because i have 13 columns and 13 rows.

- Expand the entire Tree. Check/Uncheck a Car with/without SuspendLayout. --> GetCellData is invoked 169 (13x13) times. SuspendLayout has no impact.

- Press the CheckAll Button. --> GetCellData is invoked 1521 times. 169 times for each Car row. SuspendLayout has also no impact.

In my Real App GetCellData is invoked over 200'000 times. The Application slows down extremly.

Why it's neccessary to call GetCellData for all Displayed Rows, if just one Row is edited. I think GetCellData should be called only for the edited Row.

Thanks and Best Regards
Giuseppe
Back to top
View user's profile Send private message
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Tue Sep 20, 2005 10:32 pm    Post subject: Reply with quote

Thanks for the sample project. We will do some analysis on this next week and let you know.
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Sun Sep 25, 2005 11:17 pm    Post subject: Reply with quote

We've had a look at your sample app and you are right - there is an issue here - although not as bad as you think. The problem is that DataSets and DataTables have no mechanism for turning off notifications. This means that they generate copious numbers of DataChange events during initialization. SuspendLayout/ResumeLayout do work if you use them in your Form Load event to bracket the code loading the dataset. This reduces the number of calls to GetCellData from 806 to 104 during initialization - the number required to display the initial data.

If you make a change to the Dataset that results in a change notification (after VirtualTree has loaded the data initially) then GetCellData will be called for each of the displayed cells. In your case checking a single sub-item will cause each of the currently displayed cells to be updated (ie 113 calls). This should not really be performance issue because the number of cells updated will not exceed those displayed on the screen.

The potential problem in your case is the method that Checks All/None. In this case you are making a large number of changes to the Dataset and unfortunately Suspend/ResumeLayout does not help here. Each individual change then results in a call to UpdateRowData which in turn calls GetCellData for each displayed cell. In fact if you remove the code which is updating the form.Text from GetCellData then this code still runs without any perceptible lag.

However it would be nice to be able supress the extra calls to UpdateRowData in situations, such as this, where the Data Source does not support suppression of notifications. We will add SuppressDataUpdate/ResumeDataUpdate methods in the next release to allow for this.
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
flc.net



Joined: 21 Jun 2005
Posts: 89
Location: Switzerland

PostPosted: Tue Sep 27, 2005 7:31 am    Post subject: Reply with quote

Infralution wrote:

However it would be nice to be able supress the extra calls to UpdateRowData in situations, such as this, where the Data Source does not support suppression of notifications. We will add SuppressDataUpdate/ResumeDataUpdate methods in the next release to allow for this.


Great! Thanks a lot.
Giuseppe
Back to top
View user's profile Send private message
RGabo



Joined: 21 Sep 2005
Posts: 11

PostPosted: Tue Sep 27, 2005 5:24 pm    Post subject: Reply with quote

You guys provide the best support, ever. Amazing. All my respects!
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Fri Sep 30, 2005 10:38 am    Post subject: Reply with quote

Version 2.1.0 has now been released it includes the promised SuspendDataUpdate/ResumeDataUpdate methods and also improves the handling of ListChanged events when only one row is changed - in this case GetRowData/GetCellData will now only be called for the row that has actually changed.
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Infralution Support Forum Index -> Virtual Tree Support All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group