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 know that I've ever been a situation like this where the problem was not my architecture. In this example, it feels like your producer and consumer are coupled. Perhaps not a problem when it is in the same VI (two loops tied to the same front panel), but it opens a can of worms (corner cases need to be handled in a consistent manner) when they are not.
@Mark.Ridgley wrote: 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 disagree. All the information in the "cluster" of event data can be dealt in a pure byValue manner. The refnums are locally-scoped and the values are just data. Re-entrancy does not pose a problem in these cases. But your next comment clarified something for me:
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
That is information that was not in your original post. I had interpreted your suggestion "useful to know the last event handled" as a request to get the value of the last event. A string containing the name of the previous event brings a different interpretation. It is generally not "good practice" to use a terminal's label to make decisions, but I know we do this all the time and it works. 😉
In my opinion, idea that event structure have trace of LastEvent Is a good idea. For sure, not the only way to manage situation where order of two events Is important, but It could be useful to improve code efficiency and to have block diagram more clear.
A) Creating a dependence on the immediate previous event would be a fairly bad idea in most code I've ever looked at -- there's just too many ways that events can pile into an event queue, and all it takes is one event interjected to completely skew your behavior. Adding this would encourage unstable development practices. Instead, it is better practice to define states that the UI transitions into and out of based on different events occurring, and other events change their behavior based on the current UI state.
B) If you really need this functionality and you're confident that your event ordering will never vary, then this is straightforward to implement with a shift register that you update in every frame of your event structure.
I would strongly oppose adding this to the event structure.
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.
But this discussion will be exactly what happens at length in a LabVIEW developer meeting when talking about a new proposed feature. All the pros but even more so the cons will be brought up and if there is even one con that makes a feature less than easy to handle, has any potential to confuse the user and/or feels convoluted, the feature has pretty much zero chance to be implemented.
Someone like Aristos Queue might have had a little chance of tilting the scale slightly if a particular feature is very important for something else he was working on, but not that much. 😀
There are other, much lower hanging fruits and pretty much uncontroversial feature requests that haven't been implemented yet!
I think it would be even better if that terminal is given outside of the structure so that you don't need to wire it through each case, really useful if you want to debug some spaghetti code quickly...
