subscribing to events in controls in a separate window in another window ?

[Bill Woodruff]

< .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

 

[Bob Powell [MVP]]

Hi Bill,
This shouldn't be a threading issue because UI will all be on the same
thread unless you've done something out of the ordinary. To verify that it
isn't (or is) the handler should check InvokeRequired before modifying any
properties or calling any methods on the object that handles the event call.

private void secondaryTVHitHandler(object sender TreeViewEventArgs e)
{
if(((Control)sender).InvokeRequired)
//access won't be threadsafe... invoke your own methods.
else
// do whatever, get the node from e.Node, etc.
}


--
--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.