Programatticaly disabling radio button choices

[jtaclas]

I was wondering if there was a way I could have a set of radio buttons that correspond to files in a database, and disable specific buttons when the corresponding file does not exist.  I only seem to be able to disable the whole radio set at a time.

[Russ_Evans]

Hi jtaclas,

Try right clicking on a single radio button selection and choose "Create"  then "property node" . Now with that property node you can disable the single selection programatically.

hope this helps

Cheers,

--Russ

[Darren]

You can also use the Controls[] property of the Radio Buttons Control to get an array of references to all the booleans inside the Radio Buttons Control, and disable them that way.

-D

[jtaclas]

Basically, in my program, I have 12 radio sets, with 12-28 boolean controls each.  Although I'm considering this option, I'm looking for an option other than creating 200+ property nodes, but thanks for your help.

[jtaclas]

Hmm, when i use the Controls[] property, I find that I get a 9 element array, whether my radio selections have 12 or 28 boolean controls.  Any ideas on what the problem might be?

[Will.D]

You don't need to create 200 some property nodes.  If you feed each "controls[]" array to an indexing for loop input, you can deal with each set of radio buttons with one property node.

As for the array size always being 9....  Not a clue.  Post your vi?

[Jarrod_S.]

I can't reproduce this in LabVIEW 7.1 or 8.0. What version of LabVIEW are you using? A 12-element radio button outputs 12 references using the Controls[ ] property node. Can you post code that shows this? I am curious about this number 9. That is the default cluster size created using the Array to Cluster function. Are you converting the array of references into a cluster fo references? If so, you can change the number of cluster elements created by right clicking the Array to Cluster function and selecting Cluster Size from the shortcut menu.

Message Edited by Jarrod S. on 05-30-2006 11:31 AM

[Kevin_Price]

Jarrod / Darren:

First, sorry for the thread hijacking but I'm interested in a more official NI response to a similar issue about converting array to cluster.  Perhaps it'll even be useful to this thread's originator.

Summary: I have some typedef'ed clusters consisting entirely of Boolean LED's.  I did some processing based on converting cluster to array, performing some array-based operations, the converting back to cluster.  During development, the # of Booleans in the cluster would need to change.  Then I'd need to search out all the "array to cluster" conversions and enter the new size.  I wanted a method that didn't require manually changing all these hidden values.

Through trial-and-error experience, I discovered a technique that seems to work reliably under LV 7.1.   I would typecast from an array of Booleans to a cluster of Booleans, using a typedef constant wired to the 'type' input.  It always produced the behavior I needed, but don't know if this would be a recommended practice or not.  Particularly, will this continue to work in 8.0?  Are there some gotchas I need to be aware of ?  Here's a link to my entry in an earlier thread. 

-Kevin P.

[Jarrod_S.]

Hi Kevin,

That's a really awesome technique. I tried it out in LabVIEW 8 and it still works fine. I'll have to double check before I can get any word on whether it's officially supported, but my unofficial guess is yes. Here's why:

First of all, I type cast a boolean array and a boolean cluster to string to get a look at the underlying data structure. It turns out that for either type there is no "header" information with metadata about the element, just pure boolean data. For instance, both my cluster and array had the following type cast data when viewed in '\' Codes display as a string: \01\00\01\00\01\00\01\00 (1 = T, 0=F).

The same applied for a cluster and array of U8s. The technique worked perfectly, and the only data that was output by the type cast function was the actual numeric data in binary form. I tried it for other formats such as U32 and doubles; everything worked.

It seems unlikely to me that this underlying representation would ever change, since the type cast data is only based on the data itself, and not on its representation format (array, cluster, control type, etc). As far as I know, these formats have been constant for a long time, and there is little impetus to change them.

[Jarrod_S.]

Here's an important note from the LabVIEW help on the Type Cast function that seems to bolster my original statement:

"If you are casting that may contain Boolean data created with LabVIEW 4.x or earlier, right-click this function and select Convert 4.x Data from the shortcut menu to convert the data to a format that is readable by LabVIEW 5.0 and later. In Convert 4.x Data mode, this function interprets x as if the data is stored in LabVIEW 4.x data storage layout and displays the icon for this function with a red 4.x on it. LabVIEW 4.x and earlier stores Boolean data in two bytes unless the data is in an array, in which case LabVIEW stores each Boolean element in a single bit. LabVIEW 5.0 and later stores Boolean values in a single byte, regardless of whether it is in an array. National Instruments recommends reworking any application that uses the Convert 4.x Data mode as a long term solution."

So the data format for boolean data has changed, but not since LabVIEW 4.x. Furthermore, when it did change, we provided a backup method to ensure compatibility.

Message Edited by Jarrod S. on 05-30-2006 01:15 PM