BreakPoint
Rube Goldberg Code
A unique class of Rube Goldberg Code involves the (ab)use of dynamic data. I thought It deserves its own thread. Feel free to contribute:
What's wrong with dynamic data?
(I was actually tempted to also include express VIs, but lets keep it narrowly focused for now)
These two examples are taken from the code posted here. There is plenty more weird stuff in there, but see for yourself).
What boggles my mind is trying to imagine how long it takes to write all this. Done right, it could all be done in five minutes. Even if this programmer would work at minumum wage, I could justify to ask for 100x minimum wage and the company would still be better off. :D)
(A) In order to read about 60 controls and write them to a tab delimited text file. We apparently need:
- A 60 frame stacked sequence, reading one control at a time. Why does order matter here?
- The outer flat sequence enforces an execution order that is already enforced by dataflow. Not needed!
- Explicitely building the long tab delimited string (The next version will have 500 controls and the primitive will no longer fit on the screen!)
- Making it into an array with one element
- write it to a spreadsheet file.
All that's probably needed is "build array" and "write to spreadsheet" file to achieve exactly the same.
Moments later, we read the same data from the file again. This time we read it as a 2D array (even though it only has one row!) and use an index array primitive to get all values, one at a time. Then we write each value to an indicator terminal AND to a local variable of the same indicator terminal. Do that also about 60 time, filling the entire screen (here is a small section).
All we need is tap into the 1D output of "read from spreadsheet file"and use a single index array resized to the proper size and connect to all indicator terminals in order. The indices don't need to be wired. None of the local variables have any purpose.
@altenbach wrote:
These two examples are taken from the code posted here. There is plenty more weird stuff in there, but see for yourself).
What boggles my mind is trying to imagine how long it takes to write all this. Done right, it could all be done in five minutes. Even if this programmer would work at minumum wage, I could justify to ask for 100x minimum wage and the company would still be better off. :D)
(A) In order to read about 60 controls and write them to a tab delimited text file. We apparently need:
- A 60 frame stacked sequence, reading one control at a time. Why does order matter here?
- The outer flat sequence enforces an execution order that is already enforced by dataflow. Not needed!
- Explicitely building the long tab delimited string (The next version will have 500 controls and the primitive will no longer fit on the screen!)
- Making it into an array with one element
- write it to a spreadsheet file.
All that's probably needed is "build array" and "write to spreadsheet" file to achieve exactly the same.
So if he is really just looking to save and load control values you can just use the OpenG sub VI "Write Panel to INI" and "Read Panel From INI". If OpenG is not an option then I would suggest not using the build array option, and instead get references to the controls using the "Traverse GObjects" to find all the string controls that match the pattern. Then getting the values in a for loop using the references. Then if you add a new control you don't need to change the code at all. You can use this same method to set the control values using their references.
Intaris wrote:Ugh. Why am I not more productive? Becuase I'd have wasted 20 minutes getting all those wires perfectly spaced before I could continue. Sometimes OCD is a real pain.
That's why you use the Align and Distribute buttons on the wires. I don't remember what version those started to work with wires, but I know it works in 2011 (and has saved me lots of time from my OCD).
