Can't use "Latch when released" buttons when registering their Control referencies by Reg Events node...

[petrnowak]

@RavensFan : I don't need to compare clusters. I have Control refs of pressed button inside Event structure. I can use button control reference to do anything like reset to FALSE or other ....

[petrnowak]

@billko : I have got an information "Switch until relased" isn't recommended mechanical action because LV can sometimes get more then 1 event and sometimes even no one event. Is it a problem?

And overall: is it possible to distinguish PUSH BUTTON from OK BUTTON somehow? From Ctrl ref? Some property? I've tried 

[billko]

---

@petrnowak wrote:

@billko : I have got an information "Switch until relased" isn't recommended mechanical action because LV can sometimes get more then 1 event and sometimes even no one event. Is it a problem?

And overall: is it possible to distinguish PUSH BUTTON from OK BUTTON somehow? From Ctrl ref? Some property? I've tried 

---

Not "Switch until released", "Switch when released".  This generates an event when the switch is released, just as "Latch when released" does.  The difference is that you manually have to set the control value back to "FALSE".

I'm not sure what "PUSH BUTTON" means.  Is it supposed to behave like a momentary switch?  And why is it so hard to type "released"?  (I had to fix my spelling three times for each one I typed.)

[petrnowak]

@billko   All boolean gui buttons have the same behaviour. If I use "Switch when released" I should reset button back so it doesn't stay in press state i.e. true.
However I need some button work as a switch so they keep their TRUE state to the next click. Such a boolean item must not be resetted to false after click. So I need some mechanism to distinguish between them. I can add some postfix to button label e.g. "_B2" and omit reset of state if button label ends with this "_B2". The another way of distinguish buttons could be difference between various button forms. We have classic button and PUSH button (see image). If I can somehow know from control ref of button if it is PUSH or classic one I can for example use PUSH button for two state switch (i.e. dont reset it to false) and use classic button for one state button (i.e. reset after click). That way even user can easily see difference.

Sorry for mispelling "released"...

[RavensFan · Accepted solution]

If you have scripting enabled, there is a property node called Style ID that could give you information as to which type of control it is.

Now there might be several ID numbers for the buttons that might be similar in appearance, but still different.  But it should give you a way to distinguish the various buttons.

If you don't use the caption, you could hide the "code" in that .  Or if you put the code in the label, you could hide the label and give a user friendly caption to name the button.

What would be nice, but I don't know I've ever seen it, if there was some sort of "tag" property where the programmer could hide information that could be used later.  For instance, when I wrote a keypad entry dialog, I labelled the buttons 0 through 9 and used the label text to help determine which button I pressed.  If I could have had a "tag" property that could hold info LabVIEW didn't care about, but the programmer did, I could have extracted that data out and been more flexible with my button naming.  (Not that it mattered that much for that specific VI.)

[petrnowak]

@RavensFan:

I'll look at the scripting. btw does exist some script that can change Label of items in cluster ?????????

Hiding code in Caption is a great idea. Because putting code in label as prefix or postfix complicates code (you should fiddle with label text in gui Event structure or so...) and isn't prone to programmers mistakes. Sometimes you forget to add postfix to Label (e.g. "_B2" for button reset) and because I always hide labels this mistake is very badly visible and noticeable.

You don't need your Labels have user friendly names because buttons have Text property (even two for button pressed and not pressed) so your button can have user friendly Texts and hidden Label for use in LV code.

[RavensFan]

Yes, you can change labels, but the script has to be run from another VI and the one you are working with can't be running.

The property node for label names is Label   >> Text.

[billko]

I guess the whole issue revolves around using an array of refs instead of a cluster of refs - which is a common way to handle this.  But still, I suppose you could index each ref and give it its own dynamic event.  Then you don't have to worry about what ref has what kind of mechanical action because each button will have its own event.

I like clusters over arrays because, with clusters you can mix different reference types (like control refs, VI refs, etc.).

[petrnowak]

Cluster of refs? Cluster ISN'T indexable. Thats the main problem and main cause of using array. Cluster is perfect for small amount of refs. Array is a generic solution. I can add refs later, I can add a lot of refs and array and shared event will handle it without need to rewrite a lot of code. Thats why I use array.
I think a cluster is suitable for data vith VARIOUS data types. And array for a lot of data of the same type.

[billko]

---

@petrnowak wrote:

Cluster of refs? Cluster ISN'T indexable. Thats the main problem and main cause of using array. Cluster is perfect for small amount of refs. Array is a generic solution. I can add refs later, I can add a lot of refs and array and shared event will handle it without need to rewrite a lot of code. Thats why I use array.
I think a cluster is suitable for data vith VARIOUS data types. And array for a lot of data of the same type.

---

I think you mixed up what I was saying because I really mangled that paragraph!  Sorry about that.  I meant the "index" comment to go with the "array" comment.

There is an ongoing discussion about handling all similar events in one uber-event case vs handling them in unique event cases, and each has a similar "code confusion" factor, meaning you eventually get confused either by the sheer amount of event cases, or the sheer amount of case structure events that you have as you try to handle each instance in one uber-event case.  Name your poison.  😉

But to get back to your original question, I don't think there is a way to distinguish what type of Boolean control it is.  You might have to infer what it is by looking at its mechanical action property.