How to prevent editors from closing when background processing updates XtraTreeList Node?

Question

I'm using the DevExpress Xtra TreeList control to display a hierarchical set of questions and responses - think of a complex survey form, containing sections, subsections and a variety of questions.

The form is working in unbound mode, with no dataset nor any databinding.

As a part of the information displayed for each question, some background is obtained by calling a webservice on a background thread; results from these webservice calls are then used to populate the TreeList via calls to TreeListNode.SetValue().

Presently, these calls to SetValue() are causing any active editors to close, discarding the user's current input - a very user unfriendly experience.

How can I ensure the user's editing process is unaffected by these background updates?

The only similar questions I've found have been on the DevExpress forums, where the suggestion is a forced commit of the user's entries, which avoids loss of data but otherwise does nothing to fix a poor user experience. Since these all dated from 2007, I'm hoping the situation has now changed. Is it possible to update nodes without altering the state of the users own activity?

Background: A typical screen would have 500+ rows, with the webservice call for for each row taking around 0.6s to return. Forcibly committing or cancelling the user's actions every 0.6s is simply not acceptable, and forcing users to wait for processing to complete (>5minutes) before they can make any changes is equally poor.

Answer 1

Short answer: You can't

Changing a value in the TreeList will result in any current user editing being cancelled, reguardless of the use of Binding or not.

Official response from DevExpress:

Unfortunately, there is no way to prevent an active editor from being closed when the data source values are changed. It is impossible to achieve because the TreeList should be always synchronized with the underlying data. This functionality is implemented via the IBindingList interface in a usual manner. In response to the "change" notification the treeList must refresh itself and, as a result, reload data. This causes the active editing state to be reset.

However, there are several different ways to introduce required functionality. For example, you can create a separate form that will contain a set of editors that will provide the ability to edit a specific object directly. Another possible way to achieve this goal is to create some intermediate storage that will cache all changes. The synchronization with the TreeList's data source should be performed by user request.