LabVIEW
Custom Boolean breaks my event structure
Solved!
I created OK Buttons and hooked them up to my event structure, but when i changed one of them to a custom button the connection broke. My fix to this problem is converting the variant into a boolean, I was just wondering if I handled the problem the right way or if there is a better solution. This is just an example programm to recreate the bug as simple as possible.
Thanks in advance for your time.
Easiest option: change your event structure to where the custom button gets its own separate event case.
@Philipps wrote:
I created OK Buttons and hooked them up to my event structure, but when i changed one of them to a custom button the connection broke.
Stupid question: Why did you make a Boolean a type def? I would change that to a control so that the button is no longer getting its value type from another file.
@crossrulz wrote:
@Philipps wrote:
I created OK Buttons and hooked them up to my event structure, but when i changed one of them to a custom button the connection broke.
Stupid question: Why did you make a Boolean a type def? I would change that to a control so that the button is no longer getting its value type from another file.
If it's been customized, why not?
@billko wrote:
@crossrulz wrote:
@Philipps wrote:
I created OK Buttons and hooked them up to my event structure, but when i changed one of them to a custom button the connection broke.
Stupid question: Why did you make a Boolean a type def? I would change that to a control so that the button is no longer getting its value type from another file.
If it's been customized, why not?
Because it is still just a Boolean. Type Defs are really made for custom data types, which I generalize down to enums and clusters. When you just want a special looking button, you make the ctl a control.
@Philipps wrote:
My fix works way to good to make it two event structures.
You may need to look up some training tutorials to learn some more LabVIEW basics. An event structure can consist of many different event cases, each one of which can be configured to respond to one event or multiple events. Right click your event structure and click "Add Event Case..." to make a new case.
You can have a separate event case for each and every one of your Booleans, or if some of them have similar functionality, you can do what you're currently doing and group them into a single case.
Edit: Explanation of the variant data type: you have a single event case that is handling Value Change events for all your controls, which now are two different data types (Boolean and TypeDef). Because there is more than one data type to handle for this event case, the "New Val" and "Old Val" terminals are variants so that the wires can either hold either data type.
@Philipps wrote:
My fix works way to good to make it two event structures.
Be careful with your wording. The recommendation was to use a different event case, not a whole new event structure. It would be simple to "duplicate event case". I'm also not a fan of that since you literally have duplicate code, creating more points of failure.
@crossrulz wrote:
@billko wrote:
@crossrulz wrote:
@Philipps wrote:
I created OK Buttons and hooked them up to my event structure, but when i changed one of them to a custom button the connection broke.
Stupid question: Why did you make a Boolean a type def? I would change that to a control so that the button is no longer getting its value type from another file.
If it's been customized, why not?
Because it is still just a Boolean. Type Defs are really made for custom data types, which I generalize down to enums and clusters. When you just want a special looking button, you make the ctl a control.
Interesting. I've never typedef'd a Boolean - even a custom one - because they always happened to be inside a cluster. I never realized until now that it's for the same reason you just described. i.e., because it is in a cluster, I don't have to make a separate control to retain its customization, but the reason it isn't typedef'd is because the type doesn't need to be defined; it's just a plain old T/F no matter how you look at it.
@Philipps wrote:
My fix works way to good to make it two event structures.
As others have said, this is a really (really!) bad idea unless you actually mean two event cases of the same event structure.
There are still many unanswered questions. We can typically help much better if you could attach a simplified version of your code.
A picture never tells the whole story (e.g. "What's in the TRUE case? What's the purpose of this event case? What's in the other event cases (e.g. timeout), What is the mechanical action of the booleans? What does the program do? etc. etc.")
Where are the terminals of all these booleans??? If you would place the terminals inside their event case, you would not need to jump through flaming hoops using the variant value from the event data node. Right?
Please feel free to attach your final "fixed" version so we can see if it looks reasonable and potentially offer alternatives.
