Allow Class Events for Register for Event Nodes

[BrianGShea@NGC]

Allow LabVIEW Classes to be wired directly to the Register for Events Node and create a drop down list of events the class and ancestor classes expose.

Events will be defined like properties, a special folder type (Event Definition Folder) with a nifty overlay. A single VI will be defined that will output an event reference. The Register for Events Node can traverse the class hierarchy, and build the drop-down menu based on the Event Definition Folder names. Separators can be used to break the Events down by class type (like properties on controls and indicators).

A new right-click action on the class will allow the event to be created from a default pattern VI. The VI should just have an empty cluster or simple control type wired to a Create User Event node.

Maybe if a user event reference control is in the class' private data, a right-click action to create the event from the control and named it as it is named in the class' private data.

[Intaris]

The only part which, for me, is worth paying attention to is that syntax suggesting an event paradigm is supported when it actually is not supported is problematic.  That sounds like a fair objection to me.

[AristosQueue (NI)]

Thanks.

[Intaris]

I'm confused as to whether Brian is for or against his own idea.....

[BrianGShea@NGC]

I'm not against my idea. However, it is not feasible (with current LabVIEW) nor is it needed. If at any point in time the LabVIEW developers change the nature of classes to make this idea feasible and still follow the data flow paradigm, I would push for it.

The event paradigm is possible, but not implemented. It will be left to the developer to implement the event paradigm.

Two things are certain, the datatype of the event cannot be the class itself and the VI reference cannot have a connector pane that has class controls or indicators associated as both of these cannot be stored within the class' private data or the data of a DVR stored in the class' private data.

[Intaris]

Failing to draw any relevant connection between Brian's post and what I have been trying to convey, it's clear to me that the Idea I have been arguing has nothing to do with the OPs actual intent.

I would, however point out that it is quite feasible to return datatypes from a class method including definitions of the class itself.  There's no law stating that values returned by an accessor need originate from the private data of the class itself....

[AristosQueue (NI)]

> There's no law stating that values returned by an

> accessor need originate from the private data of the class itself....

Correct. But how is that relevant? Whether it is in the private data or not doesn't affect the inherency problem.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.