Leaderboard

If you dynamically registered for an event that you had never included in your code, there would be no frame of the event structure that would handle that event. The Event Structure has to have a frame for handling an event of type XYZ. You can change which particular event of type XYZ you're registered for (one coming from VI X or one coming from VI Y or a different user event of the same type) but you have to have a frame to handle whatever that event happens to be. To register for a truly new event, one that isn't in the event structure, you'd need to supply not only an event refnum but also a VI refnum of the VI to be invoked when the event is fired. That VI would need to have 1+M inputs and 1+N outputs, where M is the tunnels on the border of the Event Structure plus one for the cluster of the event data itself (the node on the border of the event structure) and where N is the number of output tunnels from the Event Structure plus one for the output cluster of the event (the dispose? output if it exists... I'm not sure if there's any other event outputs). Thinking about this also made it clear to me why we cannot ever support polymorphism of the user event wires. It is the wires themselves that propagate the types to the Event Structure. Those types have to be known at *compile* time. If you upcast all the wires, it would be no different than if you had created all your events with LabVIEW Object in the first place: you'd loose all the type safety in the Event Structure, and all the events would be named the same. Now, consider this: What's the solution? (When reading this picture, pretend that Graphics.lvclass is named something like "Event.lvclass" and "Point.lvclass" is a derived class of "My Specific Event.lvclass"... doing that pretending will make it easier, I suspect, to get the idea.)

No, I don't mind

Here is version which properly (I hope) tests the data type. I used Compare Data Type (private) method of Application. There is also Compare Type method which compares type descriptors. I also added automatic calculation of proper offset to center the wire (for y coordinate). You could also think of calculating x coordinate from cursor position. Insert_AS2Q_vug.llb

The wire datatype is always a datatype of its source terminal, which is always first element of Terminals[] property of the wire. And Terminal has Data Type property (variant) and Type Descriptor property (which is not exposed in scripting, so you have to use Scripting Workbench or PMS Assistant to get it). What concerns not centered wire - I can't open your code (please save in 8.2) but I belive that you should use Create Described Wire method providing as wire description start and end points which should be center terminal points (see my previous post). Remember that coordinates should be provided in reversed form (y,x). Check out how I do it in my Weird Wires plugin.

These are the only ideas I can think of... a) Try upcasting your objects to LabVIEW Object. That loses your type safety but it might be acceptable in some cases. b) You can wrap them in a variant and carry around an array of variants c) The Event Registration node creates a composite event registration wire out of multiple events. Can you use that? (It's more like bundling with a cluster than building an array, so probably not much use to you.) For the record, no one has ever asked for this before and I've never thought to try this. Anyone see a reason why the polymorphism couldn't be added?

Under the Help menu there is an option to "Find Examples". This will bring up a dialog window which will allow you to search through the examples that ship with LabVIEW. Additionally you can search the forum here for examples of the producer/consumer architecture.

scripting_workbench.beta3.zip