Shortening binary numbers in case structures

[kehander]

I'm a big fan of the idea of selecting a case by building an array from a bunch of boolean controls, changing the resulting boolean array to a number, and wiring the resulting number to a case structure.  As you may know, that way you can cleanly assign a different case to each different boolean.  (Yes, an Enum control would be preferable, except I want buttons that latch.)

So the problem with this method is that when I have enough booleans, suddenly I end up with stuff like " 1000000000, 10000000000, 100000000000, 1000000000000" in my case selector, which is long and unweildly, plus it gets tricky to count all those zeroes.  Wouldn't it be great if they could be displayed in SI notation as well? I know I'm not the only one who uses this little trick.

[aeastet]

Are you using binary number for a specific reason for the case structures? We used to use the same method a few years back and we used I32 numbers to accomplish the same thing. A lot less zeros but you still have the problem that you do not know what the case is doing unless you add a text field to explian what is going on.

[tst]

Instead of changing the array to a number, use a Search 1D Array on it and search for the T value. Wire the resulting index into your case structure.

[kehander]

---

@tst wrote:
Instead of changing the array to a number, use a Search 1D Array on it and search for the T value. Wire the resulting index into your case structure.

---

Aha!  I like it.  Is there some reason someone normally wouldn't want to do this?

[Ben]

"  Is there some reason someone normally wouldn't want to do this?"

None that I know of.

Have you tried right-click on the case and changing the radix?

Ben

Message Edited by Ben on 01-15-2008 01:14 PM

[aeastet]

"Is there some reason someone normally wouldn't want to do this?"

There are much more eligant and efficent ways to better flow control and manage your data than just attaching a number to a case. Something that you will probably learn or develop as we did over time depending on how much programming that you do.

[kehander]

---

@aeastet wrote:
There are much more eligant and efficent ways to better flow control and manage your data than just attaching a number to a case. Something that you will probably learn or develop as we did over time depending on how much programming that you do.

---

Well, that's a bit of a tease, to put it nicely.  Are you perhaps referring to event structures?

[Ben]

"Well, that's a bit of a tease, to put it nicely."

Ditto that!

Ben

[aeastet]

No it is more sophisticated than that. We developed our own system to do this kind of control. I would explain it to you but I would be giving away a competitive advantage. I will just leave you with the thought that you do not have to do things the way Labview tells you to do things. There are much better ways to program.

[tst]

There are certainly other ways things can be done (enums, as the original poster mentioned, LV classes with dynamic dispatch, variants, queued state machines, etc.), but there are place where simple solutions like this are also possible.

One example that comes to mind is when I have a few similar controls that all call the same piece of code, but each with an added piece of code of its own. I could write an event case for each and then go to a single state in a state machine or an event handler, or I could move the shared piece of code into a subVI, but it's much easier to build them or their references into an array and use that to find out which control was the one which was changed.