< .NET 2.0, VS Studio 2005 Ent., Win XP Pro SPII, all .NET Frameworks from
1.0 to 3.5 installed >

... note : normally I do not cross-post, but I felt this scenario justified
sending to both the controls and windowsforms groups ...

Hi,

1. Main form creates other top-level winform windows at run-time (new window
parent == null) from a pre-defined form template as :

secondaryFormTemplate newSForm = new secondaryFormTemplate();
// set formborderstyle, set to topmost, toplevel, etc.
newSForm.Show;

2. On each secondary winform you create there is treeview (which has public
accessor); you subscribe to the After_Select event of each Treeview IN THE
MAIN FORM with the same event handler in the main form like so :

newSForm.myTreeView.After_Select += new
System.Windows.Forms.TreeViewEventHandler(secondaryTVHitHandler);

3. so the handler for all secondary treeview selection in the main form
looks something like this :

private void secondaryTVHitHandler(object sender TreeViewEventArgs e)
{
// do whatever, get the node from e.Node, etc.
}

This compiles okay, seems to work okay most of the time, but once in a while
it appears that node selections in some of the secondary windows are not
reported to the subscriber in the main form.

So, I switched back to the more "classic" paradigm of having the secondary
form template implement an After_Select event which raises a public event,
which I then subscribe to in the main Form. Intermittent problems of some
selection events went away.

My question is : were the glitches I observed using the first technique
possibly a result of threading problems involving separate independent
top-level winforms ? Another hypothesis :  the .net TreeView (now, like me,
so long in the tooth :) is, as we all know, a wrapper around a COM control
... issues related to COM ?

My sense is that it is "best practice" to have objects raise public events
from their own internal private events, rather than have "alien objects"
subscribe directly to events of objects, but in the case where the secondary
objects (winforms in this case) are being created at run-time by a "master
object" it is "tempting" to just subscribe to their events there.

Appreciate any comments, recommendations, insights !

best, Bill Woodruff
dotScience
Chiang Mai, Thailand