LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
Mark.Ridgley

Add "LstEvt" (Last Event) to the event data node

Status: New

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

 

LastEvent.png

 

16 Comments
Mark.Ridgley
Member

..

JimKhertzian
Member

Which data structure would be that node like?

Mark.Ridgley
Member

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.

normandinf
Member

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.

GCentral ChampionCLA
Mark.Ridgley
Member

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:

 

Last Case.png

 

 

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
Member

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
Member

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
Member

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

 

str.png

Mark.Ridgley
Member

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.

Mark.Ridgley
Member

This idea generated 26 likes on LinkedIn in the first 24 hours it was posted there:

https://www.linkedin.com/feed/update/urn:li:activity:6749385266819063808/                  12 likes

https://www.linkedin.com/feed/update/urn:li:activity:6749385226520199168                     8 likes

https://www.linkedin.com/feed/update/urn:li:activity:6749384898026500096                     1 like

https://www.linkedin.com/feed/update/urn:li:activity:6749385089077047296                     1 like

https://www.linkedin.com/feed/update/urn:li:activity:6749385181154603009                     4 likes