From: Shawn Fessenden (shawn@vrfarchive.com)
Subj: [vrf] Glomming .NET Events in VEE, Part 2
Date: 2008-05-25 18:09:20
MID: 0000000054D9884439D2CE4AB325992309F09DE884B68C00
Atch: Glom2.zip (4815 Bytes)

DOWNLOAD
Get Part 2 here.
If your mail system strips the attachment that is.

SETUP
Delete the Glom.dll included with Part1 and replace it with the Glom.dll included with Part2. Open .NET Assembly References, select Glom and import GlomClicks. Close all them & you're all set.

Ok, so now we've got all the ducks in a row and are ready to shoot this wonderful information back to VEE to handle button clicks with one function. This happens through another .NET event. The event is generated from the ConglomerateClicks instance via a publisher delegate:

public delegate void GotClick(object sender, EventArgs e);
public event GotClick Click;
void Handler(object sender, EventArgs e) {Click(sender, e);}

Surprise, all done. You can probably see how the whole thing works now: The subscribing delegate is attached to a button.Click event and points to Handler. When the button is clicked, Handler is executed. Handler in turn fires event Click, which passes the information up to VEE (which has subscribed to the Click event by virtue of having a User Function named <Name> _Click, where <Name> is the name of the ConglomerateClicks object var).

CLEANUP?
I'm sure you noticed yesterday that a new subscriber delegate is created for each button subscribed to:

public void SubscribeTo(Button source)
{
// Subscribes our handler to the source's Click event.
source.Click += new EventHandler(Handler);
}

So... what about getting rid of these? After that code executes, the delegate belongs to the button object, so as long as the button exists the delegate exists. As far as I'm concerned, it should be the responsibility of the owning object to free resources so when the button goes out of scope it should destroy the delegate. However, I'm not entirely certain that will happen. I'm too lazy to check for leaks right this moment though :-)

OTHER TRIVIA
There are a couple issues that remain:

First, how do you tell what button was clicked? The answer is that the sender (the button object) is passed to VEE, so you can use any of its properties to figure out what button it was. Most notable are probably Name and Text. There is also a massively useful Tag property that the button defines as System.Object so anything can be stored there.

Second, you've no doubt noticed a slight wrinkle in this otherwise wonderful plan: the panel is going to contain other controls and you're probably going to want to reference them in the handler function, so how do you do that? Again, the sender (button) is passed to VEE, and you can use sender.Parent to get the panel object itself, and thence the Controls collection.

See the User Function Glom_Click for details.

WHAT ABOUT OTHER EVENTS?
Well, you've no doubt noticed that the subscribing delegate is added to source.Click. GlomClicks.cs can easily be expanded to GlomEvents.cs by simply adding subscription Methods & publishing Events to communicate back to VEE.

MULTIPLE INSTANCES?
Yes, you can create multiple instances of ConglomerateClicks to handle buttons on various panels or screens. There's no need to choke the Click User Function with extraneous junk because you've got a lot of real estate to manage. The publishing delegate is an instance variable, not a class variable as is sometimes done. Each one you create sends its events to the VEE User Function <Name> _Click so you can handle, say, test setup & test operation UI in different functions.

And so there it is. No more messy UI handler support, no more two buttons for one click, and a clear and simple method for hooking up events.
-SHAWN-

---
You are currently subscribed to vrf as: vrfarchive@vrfarchive.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive
Search the Agilent vrf archive at "http://vee.engineering.agilent.com/