Rube Goldberg Code

[jcarmody]

---

@grahamwebb wrote:

Hi, this is my proper profile (and a testament to my lack of memory!)

I'd like to present this code for ridicule consideration as a Rudy Goldberg construction. It's one of those "I'm sure there's a better way, but I've started now so it will do".

A previous sub-vi searches for numbers and strings in a continuous stream of data (in a non-LabVIEW xml format), this ties them together.  

---

Just a thought, after my eyeballs cooled.

[SteveChandler]

---

@grahamwebb wrote:

Hi, this is my proper profile (and a testament to my lack of memory!)

I'd like to present this code for ridicule consideration as a Rudy Goldberg construction. It's one of those "I'm sure there's a better way, but I've started now so it will do".

A previous sub-vi searches for numbers and strings in a continuous stream of data (in a non-LabVIEW xml format), this ties them together.  

---

I really like it when people pay attention to block diagram neatness. Absolutely beautiful wiring job!

[James_W]

---

@jcarmody wrote:

---

@grahamwebb wrote:

Hi, this is my proper profile (and a testament to my lack of memory!)

I'd like to present this code for ridicule consideration as a Rudy Goldberg construction. It's one of those "I'm sure there's a better way, but I've started now so it will do".

A previous sub-vi searches for numbers and strings in a continuous stream of data (in a non-LabVIEW xml format), this ties them together.  

---

Just a thought, after my eyeballs cooled.

---

- But that doesn't handle the special case "SACRUM", putting the contents of that VI or even all of the common code into subVIs would really increase readability to start with.

[grahamwebb]

A spanner has been added into this vi's works this morning, because I need to filter each channel. What was a curiosity has become today's work!    

[altenbach]

Coloring rows of a table according to a field value can be done in many ways. Here are two...

(seen here)

[Ben]

---

@altenbach wrote:

Coloring rows of a table according to a field value can be done in many ways. Here are two...

(seen here)

---

Maybe my coffe is not working but...

shouldn't everything after the "Serch 1d array" be in a case structure driven by the index returned by the Search... where the code shown is in the default case and there is nothing in the "-1" case?

Ben

[altenbach]

---

@Ben wrote:
shouldn't everything after the "Serch 1d array" be in a case structure driven by the index returned by the Search... where the code shown is in the default case and there is nothing in the "-1" case?

---

Yes, the code is just a draft. In the example data given, there are no field values that don't exist in the comparison, so it is not needed. We seem to be dealing with a limited set of possibilities.

However, your code suggestion is still flawed. For correct operation, we still would need to feed the default color in the -1 case, because the row could have had an assigned color from an earlier field value. The color needs to be re-written no matter what.

Even if we want to deal with that possibility, we still don't really need a case structure: FOr code simplicity, we would just add a "+1" before wiring to the index and shift the color lookup array up by one index, with index zero now being the default color. 🙂

(If the table is big, there are other issues. For example we should probably defer panel updates during the coloring operation. If only very few fields should get colored, we would do a pass coloring the entire table with the default color and then selectively update only the few rows with "special" data. Here, your "case" suggestion would the the way to go. 😄 If we know the typical data, we can always finetune. Every situation is different.)

[elset191]

http://www.youtube.com/watch?v=Ntu7iHmKxDg&feature=player_embedded

Any other halo players out there?

[Ben]

---

@altenbach wrote:

---

@Ben wrote:
shouldn't everything after the "Serch 1d array" be in a case structure driven by the index returned by the Search... where the code shown is in the default case and there is nothing in the "-1" case?

---

Yes, the code is just a draft. In the example data given, there are no field values that don't exist in the comparison, so it is not needed. We seem to be dealing with a limited set of possibilities.

However, your code suggestion is still flawed. For correct operation, we still would need to feed the default color in the -1 case, because the row could have had an assigned color from an earlier field value. The color needs to be re-written no matter what.

Even if we want to deal with that possibility, we still don't really need a case structure: FOr code simplicity, we would just add a "+1" before wiring to the index and shift the color lookup array up by one index, with index zero now being the default color. 🙂

(If the table is big, there are other issues. For example we should probably defer panel updates during the coloring operation. If only very few fields should get colored, we would do a pass coloring the entire table with the default color and then selectively update only the few rows with "special" data. Here, your "case" suggestion would the the way to go. 😄 If we know the typical data, we can always finetune. Every situation is different.)

---

I don't want to rube you the wrong way Christian but I understood the rule of your thread here that the un-rubed version had to be functionally equivelant.

Take care,

Ben

[altenbach]

---

@Ben wrote:
I don't want to rube you the wrong way Christian but I understood the rule of your thread here that the un-rubed version had to be functionally equivelant.

---

That's sometimes hard to prove, especially since I did not shows the other cases of the case structures. 😉 I don't think such a rule can be strictly enforced. Many examples here behave slighly differently for edge cases. If anything, the suggested alteratives are often less buggy or add functionality. 😮

In this case, the code fragments were equivalent within the confines of the example data. Good enough for me. 😄