Wow, that rocks! Great! Thanks a lot for the reply and demo project, Milko! Yes, must be something in our code, sure enough.

Yes, we do it a little bit different to your demo project. We do also format the columns in OnColumnSetGenerated. And our styles are a little bit more sophisticated. Then, we need to allow cell editing depending on various criteria (e.g. is the employee valid/active in a month and so on). At the last node level, we have to differentiate between different line types (for salaries that can be edited, for vacation that is calculated etc., all with different formatting). Then, we do the formatting directly on the existing Appearance objects. We do not define and reuse our own Appearance objects. Maybe this costs a lot performance? I will try that in our application.

In order to show you how we format the tree I like to send you our TreeFormatter class. We extract all the formatting logic to this class. It's not a running application as you suggested, but maybe you can see critical mistakes we do. The method SetupManningGuideDataNode is called in the InitializeDataNode event handler for each node. You can see what we do with each node in this method. Commenting out this code gives a boost of about 50-60% but populating data nodes costs still about 1-3 seconds.

We do no calculations depending on columns. All data including calculated data is coming from the server. We have the data tables in the data set and simple bind it to the control. But as mentioned above, we do formatting based on columns. Please see the attached TreeFormatter class again. There is the method SetupColumnSet that is called in the ColumnSetGenerated event handler.

I changed the references in your project back to 12.2. The version we use currently in the production version. Your application stays amazing fast with it. So I think there is no issue in the version we are using. Must be our code.

So I would really appreciate any hint or advice from your side. We are fighting with that problem at some customers which are really dissatisfied with OUR application. We really want to make it faster and I can not believe that this won't be possible with your controls. :)

Many many thanks for the demo and in advance to your answer!

Hi Milko!

Thanks a lot for your answer and the tips! We are heavily working on it and evaluate your suggestions. Problem is, that we have to deliver asap to the customer. So we are working on the product while evaluating your suggestions. That's why I did not answer the last day. 

Lazy loading sounds good. I'll have a look on it from now. Regarding this, I have some further question. In hope, that you can give me some further hints since I cannot find Best Practices in your documentation. Maybe you can guide me to the correct websites. So here are the problems:

1. The user works in the tree and edits values. There are rows (e.g. the employee benefits) that depend on the changed values. So we like to update the calculated rows while the user is typing. Do you have some best practices for requirements like that regarding the tree? How to update the data table rows and prevent the tree from complete rebuild? 

2. The user can add employees to positions. We do that by adding the new rows to the appropriate data tables. But if we do so, the tree rebuilds completely. The user defined view (expanded/collapsed nodes) goes away because the tree is rebuilt. How can this be handled?

Hopefully, you have some solutions for me, I am looking forward to your answer!

I will respond to your last answer and mark it as solution, if it helps in some way. But for this, I have to try the lazy loading stuff now. :)

Many thanks in advance!

Robin

Hello Robin,

Thank you for your feedback.

Please find bellow answers to your questions:

1) Could you please clarify who and how makes those calculations on your calculated rows? If you are using ADO.NET you probably use Expressions so in this case you should update the underlying data table, but this won’t involves rebinding of your tree. Actually rebinding is “expensive” operation, so you should avoid it, instead just update the underlining data source and UltraTree will reflect those changes.

2) Adding a new row to a particular table in your data set does not rebind entire tree. Please check attached my revised sample solution where I have add similar functionality. By clicking the Add Row button you can add a row to the underlying data table and it appears in the tree.

If you could provide us simple sample which demonstrates your issue or to modify my sample, it will helps me to understand better your issue.

Please let me know if you have any further questions.

Hi Milko!

Thanks a lot for your answer!

1. We do the calculations at the service backend and request the changed data again or return it directly by the services. Then we update the data tables via DataTable.Load method with LoadOption.Upsert. Works fine now! But the new problem is, that after upserting the changed data into the data tables, the user cannot leave the current row where he changed a value (and therefore a cell was in edit mode). No other row is clickable, row selection does not change. No events are fired from the tree anymore. Looks like a freeze of the tree except in the last current row. Maybe DataTable.Load is not a good idea? Do you know this problem somehow?

2. Adding new rows via DataTable.Load works pretty good and VERY FAST! :)

I try to extend your demo to show the problem from point 1. It's easier than to send you our code. Hard to extract an example from it.

Cheers!

Robin

Ok, I extend your project in the way we do updates of the data tables. Please have a look into ultraTree1_AfterCellExitEditMode. So if you change values and tab through the cells or click somewhere else after editing, you can see an error that is not catchable in my code. It is not really the same problem I described above with the "freeze" but goes in that direction.

So maybe I should update data table rows manually, not with the DataTable.Load method...

Find the project attached.

Robin

When I replace this code

boundTable.Load(updatedTable.CreateDataReader(), LoadOption.Upsert);

by this code

foreach (DataRow row in updatedTable.Rows)
{
    var values = (from value in row.ItemArray select value.ToString()).ToArray();
    UpdateInsertManningGuideRow(boundTable, values);
}

private void UpdateInsertManningGuideRow(DataTable tableToUpdate, string[] values)

{
    if (tableToUpdate == null)
        throw new ArgumentNullException("tableToUpdate");

    if (values == null)
        throw new ArgumentNullException("values");

    var id = values[1];

    if (!tableToUpdate.Rows.Contains(id))
        tableToUpdate.Rows.Add(values);
    else
    {
        var row = tableToUpdate.Rows.Find(id);
        row.ItemArray = values;
    }
}

It works for me! There is no freeze anymore.

Hello Robin,

I am following up to ask whether or not if you have any additional questions with our UltraTree control? If so, please let us know so we can assist you further. Thank you and have a nice day.

Hello Robin,

Thank you for your feedback.

If I understand you correctly when the user updates a single cell you are sending updated information for this cell through services. Then you perform some server side calculations and return all tables trough the service again. Can you tell me do you really need to send back all tables? Does your scenario allows to get only the updated rows? This should speed up the process.

Regarding freezing is it only the tree that freeze or entire form is frozen? How long does it freeze? Does the tree start to respond again or it hangs at all? Depending on your scenario one possible reason for this freezing may be slow handling of the request you send to the server.

DataTable’s load method when called with LoadOption set to Upsert actually loads all new rows while retain the old ones. Is this your scenario? This will load again entire data set each time the user change the content of a cell. However I believe that if your scenario allows it, it is better to retrieve from the server only changed rows. Please let me know if this is possible in your application.

Waiting for your feedback.