boolean control for integer value

[BPerlman]

I am writing wrapper VIs for a DLL, and demo programs to, well, demonstrate their use

I have several functions which take the same structure as an input.  This structure has several integer fields (U16, if you must know) which are logically booleans (that is, only valid values are 0 and1, and in fact at some level they are converted into a single bit each).

My VIs currently work, using a cluster that is laid out exactly like the structure.  However, I would like the interface to be prettier and easier to use.

What I want to do is to show each of these fields as a pushbutton.  However, if I change them to pushbuttons, the cluster's internal representation is now different and I can not pass it into the DLL function.

The only solution I have thought of is to have an input cluster with pushbuttons, then unbundle the whole thing, convert all the bools to ints, and then rebundle.  This is very cumbersome.

Is there any way to have an integer field appear as a pushbutton (or other boolean-style) control, while remaining represented as an integer?  Or any other createive ideas?

Thank you.

B.

[CTF]

How about this? (Make sure you set the cluster size for 'Array to Cluster')

[BPerlman]

That's a clever idea; I like it.

I don't think I can use it though, because there are other things in the cluster too.....

Sorry  I wasn't clear enough about that.

Actually, looking again, the structure I need to pass to the DLL is made up of U16 fields which are actual integers, and signed 32-bit integers which represent the booleans (this comes from Windows, which defines "BOOL" as "int").  And, since they are not organized by element size but by a conceptual order, the LabVIEW cluster needs to have padding fields too.

B.

[smercurio_fc]

Short of creating an XControl, the only other suggestion I can offer is to use a menu ring with just the string values of "0" and "1". You can set the datatype to whatever integer type you need and the increment/decrement will to essentially cycle through the two choices.

Note that you don't need to unbundle the whole cluster. You can use Unbundle by Name and then Bundle By Name to just extract the one element you need and replace the one element you need in the target cluster.

[Mark_Yedinak]

My recommendation would be to define your UI as a UI . Don't worry about creating display clusters to match the data representations you send to some dll. It is always a good practice to separate the UI functionality (which includes how it looks) from the actual processing tasks. I'm not saying that you shouldn't use clusters on your UI but that they should be representative of your user interface. Deal with any conversions of the data at the point you are calling the dll. Using this approach it would be easy to modify the low level processing (think new dlls for example) without impacting your user interface. Conversely, you can completely give your UI a new look and feel if you want.

[BPerlman]

Smercurio,

Thank you.  I don't even know what an XControl is! 

I was thinking of using unbundle by name -- but at least half of my cluster is this kind of field, so it will get a bit messy anyway.  Also, if I am taking apart one type of cluster and building a different one, with different types, is it actually possible to only unbundle part of it?  I haven't tried it, but somehow it doesn't make sense in my mind.

The menu ring is an interesting idea and sounds like it might be a reasonable solution, though pushbuttons are nicer; I'll have to play around with it and see how it looks.

Mark,

In general, I agree with you about separating the UI and the implementation, and that is how I generally write applications.  You are 100% right that it is the correct approach to engineering an application.

The difference here is that my applications are really just demos of the library we create, and thus I don't really have to worry about giving the GUI a new look and feel or such things -- there is very little chance that my company will invest engineering time in changing the look and feel of the demo programs!

We control the DLL, and we have to stay backwards compatible for our customers, so we don't have to worry about it changing.  We certainly don't have to worry about switching DLLs -- the entire purpose of this VI library is to wrap the DLL for customers who use LabVIEW!

If I were just doing this in the GUI, it would be one time and maybe I'd just do it.....but I wanted to make a custom control which would be at the interface to the VIs also (they can be run manually also).

At this point I am thinking of either the menu ring or of making a subvi which takes the UI type of cluster with booleans and does all the bundling and unbundling and type changes.  I'd still have to do it, but once, and it would be basically hidden.

Hmmmm....

B.

[Yamaeda]

Changing data types between clusters has to be done explicitly i think. Else you could have made the left cluster into a variant and Variant to Data with the right cluster. The bool to int will cause that to fail though ...

/Y