I have a Treeview control and a Propertygrid control on a form. The tree has more than 100 nodes.
On the PropertyValueChanged event of the Propertygrid, I have to perform some long running operations(typically 3 to 5 seconds) and hence I have used Application.DoEvents within this code to keep the UI responsive.

My problem is that when I follow these steps:
1. Change some text property on the PropertyGrid
2. Without commiting the change(e.g. by pressing enter, clicking on some other property row, etc) I click on a node in the treeview control.
3. Immediately after clicking, I move the mouse away from the clicked node, but within the tree.

This is the event sequence I see:
1. PropertyGrid.PropertyValueChanged event enter
2. Treeview.MouseDown event fired
3. Treeview.MouseUp event fired
4. PropertyGrid.PropertyValueChanged event exit
5. Treeview.MouseDown event fired AGAIN! (Note: no MouseUp is fired)

If I remove the Application.DoEvents calls from Propertygrid's PropetyValueChanged event, I see this event sequence:
1. PropertyGrid.PropertyValueChanged event enter
2. PropertyGrid.PropertyValueChanged event exit
3. Treeview.MouseDown event fired
4. Treeview.MouseUp event fired

The additional(unwanted) MouseDown event without a matching MouseUp is causing a drag operation to initiate; which of course the user would not want.

Is there any way to avoid the additional MouseDown event from firing? Because this event fires after PropertyValueChange exits, setting a flag while my (long running)operation executes doesnot help.
Is there any way to keep the UI responsive in this case without the use of Application.DoEvents?

I have tried this with VS2005 and VS2008, and got the same results with both.

Please Help!

Is there any way to keep the UI responsive in this case without the use of Application.DoEvents?

This is my suggestion. Rework your long running process so that it uses a BackgroundWorker .

This will keep your UI responsive, and avoid the (problematic) calls to Application.DoEvents, which can cause many issues (as you're seeing).

---

Reed Copsey, Jr. - http://reedcopsey.com

Is there any way to keep the UI responsive in this case without the use of Application.DoEvents?

This is my suggestion. Rework your long running process so that it uses a BackgroundWorker .

This will keep your UI responsive, and avoid the (problematic) calls to Application.DoEvents, which can cause many issues (as you're seeing).

---

Reed Copsey, Jr. - http://reedcopsey.com

I agree with Reed.

Application.DoEvents is basically a hack to unlock certain types of race conditions that never should have been allowed to exist in the first place.

Rudedog =8^D

---

Mark the best replies as answers. "Fooling computers since 1971."

Yes, TreeView is especially unfriendly with its events to this kind of practice. It also burbs when you change the focus during one of its events. One possible way out of this is to delay the action of the PropertyValueChanged event. 3-5 seconds is a bit long but you might get away with it without threading if you run the code when the form goes idle again:

private void propertyGrid1_PropertyValueChanged(object s, PropertyValueChangedEventArgs e) {
this.BeginInvoke(new PropertyValueChangedEventHandler(DelayedPropertyValueChanged),
s, new PropertyValueChangedEventArgs(e.ChangedItem, e.OldValue));
}

private void DelayedPropertyValueChanged(object sender, PropertyValueChangedEventArgs e) {
// etc..
}

---

Hans Passant.