Within an event struc, is there any identifying information available indicating the event trigger source?

[plyons.gks]

I'm currently trying to debug an issue and thought of this idea when I saw "source" available within the particular user event that I have returning an invalid value.

Say you have a bunch of vi's in a project that have access to a particular user event.  

If you find that one ore more of these vi's somewhere is returning invalid data passed along while generating the event, is there any way of figuring out which vi the invalid data came from?

I don't even know if this is possible, just curious

Thanks

-pat

[Hooovahh]

The only solution I can think of, is to pass along with the data in your User Event, the VI Name of who generated the event.  Then when you get the event you can parse out the VI Name of who generated it.  Some extra overhead but useful for troubleshooting.

[plyons.gks]

I'm noting this for future designs- right now my data type is stuck as a double but from here on in I'm gonna make it a string and have data parsed or something with a pipe.

Thx

-pat

[Hooovahh]

---

@PatLyons wrote:

I'm noting this for future designs- right now my data type is stuck as a double but from here on in I'm gonna make it a string and have data parsed or something with a pipe.

Thx

-pat

---

You are welcome to do what you like, but might I suggest a Type Def'd cluster?  That way you can have your data the way you want and just update the Type Def if you need to add more data later.

Of course if you do this you'll notice that the Event Ref wire (coming out of the Register) will be a different type because of the data type changing.  This is one of the reasons all my User Events are Variants, and then updating the type def, doesn't cause the Event Ref to change (since the data is still variant).  You can then get even more tricky by using the Attribute of that Variant and store other information in there too (Source, Value, Error, Destination etc).  User events are as powerful as you want but you may need to plan ahead for expandability like this.