Event Case Number

[akarns]

I have an event structure with 50 event cases.  When one of the event cases are triggered, is it possible to programmatically determine which one was triggered?  For example, obtain the number or name of the event case that was triggered?  If there is an error while the code is running, I would like to be able to tell the user what event triggered the error.

[RTSLVU]

Well right off the top of my head I would say not directly, but there are ways to do what you want.

Show us your code and I am sure someone can lead you to the best way to accomplish this.

Frankly, if you are using proper error handling throughout your program you shouldn't need much more. 

[altenbach]

Why not just branch the wire going to the case selector and display it? From the value it will take very little detective work to figure the resulting case.

What is the datatype of the case selector? Do you have complicated ranges? Do you really need 50 cases?

[akarns]

RTSLVU,

Thank you for the quick response.  I figured the answer might be as such, but I was hoping someone had possibly figured it out.  Unfortunately, I am unable to share my code.  The IP does not belong to me. What I can say is that I am developing a User Interface for a scientific application.  And, unfortunately, I am not the only one that will be using it.  In my experience, users of code that they did not write are often quite adept at finding stupid ways to generate errors.  It is all but impossible to predict what ways a user will attempt to use an application so creating error handling for every eventuality is very difficult.  So, although what I am asking for probably will not actually execute in the code, it would be useful to have to help locate errors when a user inevitably generates errors.

altenbach,

Because I am working with an event structure, there is not a case selection node.  I have 50 event cases because I have so many controls on the front panel that require actions when used.  Had I been using a case statement, I 100% agree with you.

[FireFist-Redhawk]

---

@akarns wrote:

RTSLVU,

Thank you for the quick response.  I figured the answer might be as such, but I was hoping someone had possibly figured it out.  Unfortunately, I am unable to share my code.  The IP does not belong to me.

altenbach,

Because I am working with an event structure, there is not a case selection node.  I have 50 event cases because I have so many controls on the front panel that require actions when used.  Had I been using a case statement, I 100% agree with you.

---

Can you show us a picture so we can see what type of architecture you're using? From your statement to altenbach, it sounds like you're using a one loop approach but want to confirm. If you were using a producer-consumer pattern, their suggestion would work pretty well in fact. Not knowing the type of architecture you have in place makes it harder for people to help you, as just demonstrated.

[JensG69]

How about something like this:

Regards, Jens

[pincpanter]

Every event case generated by a control exposes two properties: Type (it's an enum carrying information about the event type) and CtlRef . From CtlRef you can get the Name or the Caption of the relevant control.

Wire these two values out of the structure and build a warning dialog (or a message) to be shown when an error occurs.

[altenbach]

• Depending on what you need, maybe the event inspector window can help you debug, but it is not quite the same, of course.
• Similarly, there is even a Desktop Execution Trace Toolkit that can help you debug.
• You can see what's happening also during execution highlighting. Newer LabVIEW version have the toggle execution highlighting probe so you can trace very small sections that you suspect.

(I have not used any of this much and cannot give specific advice on suitability)

[RTSLVU]

---

@akarns wrote:

RTSLVU,

Thank you for the quick response.  I figured the answer might be as such, but I was hoping someone had possibly figured it out.  Unfortunately, I am unable to share my code.  The IP does not belong to me. What I can say is that I am developing a User Interface for a scientific application.  And, unfortunately, I am not the only one that will be using it.  In my experience, users of code that they did not write are often quite adept at finding stupid ways to generate errors.  It is all but impossible to predict what ways a user will attempt to use an application so creating error handling for every eventuality is very difficult.  So, although what I am asking for probably will not actually execute in the code, it would be useful to have to help locate errors when a user inevitably generates errors.

---

I get that it's hard to test for everything an end user can screw up but...

• Using proper Error handling you can simulate errors by injecting them into your code
• The standard message itself usually points people in the right direction
• You can add text to the standard error message
• You can define custom error codes and messages to replace cryptic LabVIEW error messages  
• Your code should also prevent "stupid" or "clumsy" errors
  • If pressing button 1 then 2 then 4 causes an error
  • Prevent the user from pressing the buttons out of sequence

[mcduff]

The following is from

https://lavag.org/topic/19263-inspect-queued-events-in-a-compiled-application/

Look at the link from Hooovahh  he gives an example that can modified that does want you want. (It will need to run in parallel with your code)

I attached Hooovah's VI here for completeness. 

You should go Kudo some of Hooovah's posts if you like the VI.