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!

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.

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.

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

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