Rube Goldberg Code

[Gabi1]

---

altenbach wrote:

If case structures never existed and we only need code in the TRUE case....

... we could use a FOR loop and convert the boolean selector to 0,1 and wire it to the iteration count.

...and if you need to pass data, you can use a shift register : it will pass the data unchanged in case the loop doesnt execute!...

[altenbach]

---

Gabi1 wrote:

...and if you need to pass data, you can use a shift register : it will pass the data unchanged in case the loop doesnt execute!...

---

Yup, use that all the time! 🙂

[smercurio_fc]

On the upside it saves you from having to wire through for the other case. No more white tunnels!  Woo-hoo!

[Ray.R]

Just goes to show that what appears to be crazy code can be quite useful!!  🙂

I've often wished there were shift registers in Case Structures.  Now we have it for simple True/False.  😄

EDIT:  now, with this new consideration, does the code still fall under Rube Goldberg?

Message Edited by JoeLabView on 02-22-2008 07:56 AM

[Gabi1]

---

JoeLabView wrote:

now, with this new consideration, does the code still fall under Rube Goldberg?

---

maybe not directly Rube Goldberg, but at least obfuscated : imagine a series of loops in loops ...

[Wayne.C]

What was it my dad used to say all the time?

"Do as I say, not  as I do." 

[Ray.R]

---

Gabi1 wrote:

maybe not directly Rube Goldberg, but at least obfuscated : imagine a series of loops in loops ...

---

No!!!!!  noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo....................................................................................................  😮

Unfortunately, I don't have to imagine..  😞

[altenbach]

---

JoeLabView wrote:

I've often wished there were shift registers in Case Structures.  Now we have it for simple True/False.  😄

---

It's more like True/False, because the false case cannot have any code yet. 😉

Of course we could make a parallel such loop where we invert the boolean and place the FALSE code in the loop.

This is for the purist who does not like hidden code. 😄

(A screenshot shows everything and we don't need to have to wonder what (if anything) is in the "other" cases.)

Message Edited by altenbach on 02-22-2008 08:16 AM

[Ray.R]

Yes, Altenbach... that's what I would do.. two loops, see everything, plus shift registers.. LOL!!  😄

Now, since we're having fun this morning, you may as well visit this thread..

http://forums.ni.com/ni/board/message?board.id=170&message.id=303660

[altenbach]

Some programmers spend way too much time on useless tasks instead of focusing on the real coding. 😄

A VI has an empty 2D array indicator, but in order to do anything with it, we need to:

1. Right-click on the terminal... show control. (originally hidden)
2. RIght-click on the array container "advanced...enabled state...enabled" (originally "disabled&grayed")
3. RIght-click again and select "advanced...show array element" (originally hidden)
4. Right-click element and select "advanced...enabled state...enabled" (originally "disabled&grayed")
5. Resize to a reasonable amount of elements (originally 1x1)
6. right-click..visible items..show index display (originally hidden)
7. Now we can "change to control" and replace the local variable with it directly and actually start testing.

Why all these "layer of protection"??!! 😮

1. If a FP element is hidden, it does not really matter if it is enabled or not.
2. If it is an indicator, is is "disabled" at runtime anyway just by the fact that it is not a control.

If we dig a little deeper, almost not a single option is at the default, the VI is

1. set to run when opened (I really hate that!) How do I stop that thing?!??
2. customized window apperance (e.g. scrollbars, tool bar and menu bar hidden. Especially unfriendly for "run when opened")
3. configured minimum panel size as 698x588 (nice round numbers at least. ;))
4. ...

Why!!!!????

(from http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=304722#M304722 )