LabVIEW
How to trigger a user event from two different sources?
Solved!
@MaSta wrote:
I wonder why no one looks at the pictures I showed above. Accessing the custom menu triggers an event, the MenuItemTag is read into a multicase (not shown in the simplified VI). OK, new image:
Because I and many others are very bad in debugging pictures! Attach your code, and do a save for previous if you use one of the latest LabVIEW versions.
As has been already pointed out if you have an event case handle multiple events, LabVIEW will only let you select attribute nodes that apply to all those events. It can't invent values of attributes that an event doesn't provide and correctly disables them in the selection.
If you want to have access to that attribute you need to handle the event in its own case. And if you want to have common code execute in both cases there are a few solutions that avoids code duplication. The first and most obvious would be to place that code in a subVI and call it in both cases. If your application gets more complicated you may however anyhow want to go to a state machine design. And then you put that code in a specific state and simply send the state machine handling into that state from both event cases.
@MaSta wrote:
@LLindenbauer wrote:
@MaSta wrote:
I wonder why no one looks at the pictures I showed above.
Please consider working on your communications skills. Multiple people replying in confusion should give you pause and make you try to give a better explanation. Being rude will not motivate others to help you. You may note that I correctly guessed the actual problem and provided two possible solutions in my answer above. Others have now provided a worked out example.
Why is wondering about something considered as rude? I showed a picture with a structure and someone asked "what is your structure?". Can you imagine how confusing that is for me?
Your intention to help in honor, but your VIs are not a solution to my problem as the question was "two different sources" not "two identical sources". LV allows you to combine two different cases into one event, but removes important refs and data so you need to get them from elsewhere. That's the problem, the question and what's shown in the two initial images. Unfortunately, the answer came from someone and was "not possible", so I gotta find a different way.
Rude is probably not the right word but you have shown certainly obstinance in my opinion. First you start with an image. Yes images are sometimes worth more than 1000 words but in the case of a LabVIEW diagram they are often not even half of the truth. There are many things such as in hidden structure frames, popup attributes of objects, etc. that can not be examined in a picture. Together with a less than perfect topic title it makes it almost impossible to determine what you tried to do without using some magic crystal ball or other psychic capabilities. Sometimes a problem strikes something I have come across recently and then there are no psychic capabilities needed. In this case this is a problem that I have discovered myself maybe 20 years ago at one time, investigated and found that a proper state machine architecture easily allows to solve it, and moved on. It's resident knowledge deep down in my memory, but not really something I actively work with in my daily work simply because I pretty much always start with a state machine and if I need to handle different events I ALWAYS let them have their own event case and trigger the according state transition from there. That's muscle memory and doesn't require to have the knowledge about incompatible events not having all the event data present in a case, at the top of my mind.
You need to consider the target audience. They haven't your problem that you tried to tinker with for some time. They come and read your post with a blank slate as far as your problem is concerned, and a picture and a few more or less well chosen words may not be enough to understand your problem.
And there have been explanations why things are the way they are and also several solutions that in all honesty are worthwhile to consider. Insisting that the mountain needs to come to you rather than you going to the mountain is an interesting concept but in all truthiness also one that is certain to fail.
