From: Shawn Fessenden (shawn@vrfarchive.com)
Subj: [vrf] Glomming .NET Events in VEE, Part 1
Date: 2008-05-24 17:02:13
MID: 0000000054D9884439D2CE4AB325992309F09DE8C4B58C00
Atch: Glom1.zip (4626 Bytes)

DOWNLOAD
Although the demo is attached, you'll probably have to
Download the demo for Part 1 here.
Probably most mail systems will strip the zip.

Don't panic - it won't run. You have to set it up first.

DEFINITION
Glomming, or conglomerating, means gathering together.

PROBLEM
There's a gotcha when using event sources with whatever language: the default case is to have one handler function for each source. When sources reach into the dozens or hundreds, this can be a sever burden to code clarity & organization.

Take for example the simple Windows.Forms.Button. It's very convenient and easy to use, but you have to have one handler for each button, and that limits the button's usefulness. Also, when using any Windows.Forms controls, it is usually desirable to place them on a Windows.Forms.Panel, and these controls are created dynamically so there really isn't a formal VEE host variable name to construct a User Function to handle events from the control.

Having run into this difficulty many times, I've usually been content to declare a "surrogate" object to handle events, but this is an absolutely terrible solution. There's nothing worse than "bloat ware", and wasting resources like this is guaranteed to produce the worst kind of bloat ware.

Even this doesn't get one away from using one function per source though, and it's that difficulty that's finally prompted me into action. Recently, a VRF member wondered how to wire events to buttons created dynamically and placed on a Panel -- there's no obvious way to do so. I explained about the surrogate method, but the inherent weakness of this method was immediately obvious.

"Is there a way to get around declaring a surrogate" the OP wanted to know? The basic problem was that the number of buttons couldn't be determined at design time. I spoke about Delegates, and how they are used to subscribe to event sources. The problem with that is I have no idea how to handle this situation in VEE. The only answer I could give was design for the theoretical maximum & hope for the best.

Then I learned that the maximum could be as high as eight hundred controls, six hundred of which would have to handle click events! Six hundred User Functions just to handle button clicks. This situation is completely unacceptable even by the very lowest of software design standards.

SOLUTION
The obvious solution is to wire many buttons of similar functionality to one user function click handler and let it determine what to do depending on which particular button is clicked, but how does one achieve that?

First, lets demonstrate that we can in fact conglomerate button clicks to a single function. At first, this will be a function in a custom assembly that simply informs you of what button was clicked. Part 2 will show how to pass that information back to VEE so one VEE User Function can handle all the buttons.

Unzip Glom1.zip and put Glom.dll somewhere -- your VEE Programs directory is convenient. Next, open Glom1.vee and open the .NET Assembly References dialog and click Browse... Select Glom.dll and click OK. Click OK again and check GlomClicks in the Import .NET Namespaces dialog. Click OK again. NOW you can run the example.

Whenever you click one of the buttons, you'll get a message box telling you what button was clicked. We're half way to cleaning up this super messy situation!

HOW IT WORKS (so far)
In the VEE program, five buttons are dynamically created and stuck on a panel. As they are created, their Click events get a new delegate tacked on to them of type System.EventHandler. Glom.SubscribeTo(btn) does this.

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

That's really all there is to it. Now, whenever one of these buttons is clicked the function Handler is called and presto: information.
-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/