LabVIEW Idea Exchange

Mark.Ridgley · ‎12-28-2020

Sometimes, it can be useful to know the last event handled by an event structure.

Mark.Ridgley · ‎12-28-2020

JimKhertzian · ‎12-28-2020

Which data structure would be that node like?

Mark.Ridgley · ‎12-28-2020

This would be a new element added to the event data node inside the event structure. It would be a string identifying the last event handled by the event structure. For example it might be a string that says "Reset Button": Value Change so that the developer knows that the last event handled was the press of the Reset Button on the front panel.

francois-normandin · ‎12-28-2020

Hi Mark,

can you give an example where this would be useful?

I'm not sure what the use case is for this, as it can be achieved with a local shift register.

The result might be unpredictable if the VI is a shared reentrant piece of code such as any actor-type overridable process. Also, for most cases where one wouldn't use this feature, the compiler would certainly need to be smart enough to not double up the memory footprint. This implies a subscription mechanism that compiles only if the LastEvent terminal were visible AND wired.

Mark.Ridgley · ‎12-28-2020

Hi, normandinf

The use case is any instance where a developer has the thought “I could do something slightly differently in this event case If only I knew which event happened just before this event case was triggered”.

I don’t want to see this discussion become a discussion of hypothetical situations trying to address every possible use case, so I’ll just say that there have been many times where I have wanted to know which event led me to the event case I’m currently in and I have not found an easy way to know that information. I know that you can achieve it with a shift register (and have done that on many occasions), but I always feel like I should not have to put so much effort into determining something that LabVIEW surely already knows.

I can determine the event by having each event case output the control reference and the type from the event data node. I pass this information into a subVI where I use the control reference to determine the name of the control that triggered the event and I then convert the type Enum into a string to identify the event. Then I combine that information to create a string like “Reset Button: Value Change”. Then I put this string on a shift register so I can use it in subsequent event cases. But why should it take this level of effort? I’m sure that LabVIEW already knows this information, so why is it such a pain for ME to know it. Here’s code I wrote that does this:

As to reentrancy and memory usage issues – I’d be inclined to believe that the other information supplied by the event data node would have the same issues, so I don’t see why Last Event should require any more resources or consideration than any of the other data supplied by the event data node. I’ll leave it to the people at NI to weigh in on that. Hopefully they will join this conversation soon.

schoenweller · ‎12-29-2020

I think it can be useful when you have a series of events that have to be done in a certain order to complete a task succesfully, have file to be opned been selected and so on, today i do this by enabling/disabling buttons if an event has been done

JimKhertzian · ‎12-29-2020

Hi Mark,

in my opinion the LstEvt node should be a refnum that would allow the developer to retrieve the full context the event was the previous time. If it's the first occurrence that refnum would be null. Indeed, it's a Pandora's box. Somebody would need to retrieve the tick count when the event happened previously, someone else would want the complete list of earlier occurences... Another developer would need to have a list of all other different events that happened in an array... If you know little of NI TestStand you know that at any point of time you can get the context and navigate in run-time through the sequence of events, but LabVIEW is not a sequencer.

Maybe you would be satisfied with a string in the application you're currently working on or with your personal development habits but believe me, it seems inappropriate.

Ideally you should keep a local cluster in which you keep your application status, you just need to manage your state properly such that you will be able to decide what to do when the event happens.

JimKhertzian · ‎12-29-2020

Hi Mark,

just to demonstrate how far it could go, imagine you have this event below. I would expect the LstEvt node to tell me if the LastEvent was discarded, or what was the FocusObj when it happened. Does it become complicated you think?

Cheers 😉

Jimmy

Mark.Ridgley · ‎12-29-2020

Hello, JimKHertzian

I said in a previous message that I don’t want to see this discussion become a discussion of hypothetical situations trying to address every possible use case.

The suggestion is that LabVIEW simply provide the ability for developers to know the name of the single event that immediately preceded the current event being handled. How this is implemented is of no concern to me. If NI were to implement a solution that provides just the name as described in this suggestion, I’m OK with that. If NI were to implement a solution that provides a refnum for the event that developers can use to look up all of the contextual data about the event (as long as that contextual data includes the name of the event as described in this suggestion), I’m OK with that too.

Thanks for joining the discussion.