Programmatically get the name of the event structure which has just run

[Worle]

Does anyone know of a way of getting the name/other relevant details of the event structure which has just run in the location in the  screenshot below.

The use case is to pass it to an error handler so the error log can contain the name of the event structure which generated the error to aid with debugging.

I suspect the only way of doing this is to put a string constant in each event structure, but I am hoping there is a way without such a high risk of developer error.

Any ideas?

[PinguX]

What are the "relevant details" do you think of ?

Perhaps the first approach to achieve what you want could be :

Then, it all depends on whether the "relevant details" are generic enough to cover all events that may occur, or not.

[GerdW]

Hi Worle,

---

@Worle wrote:

Any ideas?

---

You could use the VI name instead of the event structure label (or whatever).

How many event structures do you use per VI?

[Worle]

Both valid points, I have considered your point PinguX, it is just code which has to be put in every structure. Definitely doable, I was just hoping to find a neater solution

I already include the call chain in the error log GerdW. I tend to feel a need for doing this on configuration UI's which are manipulating classes. To maintain locality of behaviour I tend to put all my manipulation into event structures, but sometimes it can be a little challenging working out exactly what event structure caused the error.

[altenbach]

---

@Worle wrote:

I suspect the only way of doing this is to put a string constant in each event structure, but I am hoping there is a way without such a high risk of developer error.

---

It would be sufficient to have one string constant before the event structure wired across via linked tunnels. (... and I don't understand the term "high risk" here. risk of making mistakes? If a developer cannot handle string constants everything else is even more dangerous! )

An event structure typically does not generate errors, it is the code inside one of the event cases. So, more interesting would probably be which event case of given event structure contains the code that generated the error. If your code has sufficient error handing, it should be trivial t find it.

Generally, a program should have very few event structures, so if you have them scattered over all parts of the diagram, maybe even hidden inside structures, something else is probably wrong. Can you explain your architecture in a bit more detail? How many event structures? How many event cases? etc.

[paul_a_cardinale]

If you don't mind the hazards of XNodes, just drop this one inside and event case; its output will be the name of the case.

Warning, there's at least one bug in there somewhere.  Try this:

1. New blank VI
2. Put a case structure on the BD.  Leave it as the timeout event.  Don't wire anything to the timeout terminal.
3. Drop "Event Case Name.xnode" onto the BD.
4. Run the VI.  LabVIEW crashes.

[Hooovahh]

Yeah definitely some bugs. I was left in a state of broken, but running a few times. Still I love the concept. I think you should add the Copy method and have it regenerate code on that.  I did a CTRL Click and Drag making a new copy but the string constant in the generated code was still the previous value.

[paul_a_cardinale]

---

@Hooovahh wrote:

Yeah definitely some bugs. I was left in a state of broken, but running a few times. Still I love the concept. I think you should add the Copy method and have it regenerate code on that.  I did a CTRL Click and Drag making a new copy but the string constant in the generated code was still the previous value.

---

I fixed the copy bug.  But I have no idea what causes the crashes.

Do you think I need to put calls to "Setup Linker Ref.vi" in more ability VIs?