Rube Goldberg Code

[Neil.Pate]

I don't quite see how your method is much less Rube-Goldbergy. Both solutions require 5 LabVIEW primitives.

[altenbach]

---

nrp wrote:
I don't quite see how your method is much less Rube-Goldbergy. Both solutions require 5 LabVIEW primitives.

---

Since I don't sort by threading, I have no idea what you are referring to here. Please always quote parts of the original post for clarity. 🙂

Let's assume you are talking about the follwing:

So you are comparing a few diagram constants as having the same complexity as going from a single byte to an array, an array operation (toU8) and back to a single byte string. I beg to differ. 😮

(Besides, everything outside the loop does not really count because the compiler folds it into a single constant. :))

If you are really inclined to have the "+" string right inside the event case, you could do the following:

You could also omit the "ToU8" and compare with the string "\00+" (in \-codes display). same difference.

These are all details and not really important. I have seen it many time that programmers have a fear (or ignorance) of "typecast" and thus do the roundabout shuffle with the two "byte array<->string" primitives. This is never approriate unless you actually want an array somewhere. (This is along the same lines as using a "array to cluster"+"unbundle" combo as a substitute for "index array". It makes no sense.)

As long as the code works properly, it does not really matter. Personally, I tend to gravitate to the simplest and most streamlined solution, but personal opinions on what that really means vary of course. You are entitled to your opinion. 😄

Message Edited by altenbach on 11-06-2008 01:30 PM

[altenbach]

Reshaping a 1D array to a 2D array can be done in many ways. Here are two:

(spotted here)

[waldemar.hersacher]

Hello Christian,

refering to the KeyDown event.

Casting the char to U8 and comparing to '+' will delete the high byte. Will this lead to a problem on Asian or other UTF16 characters? Asian or UTF16 characters maybe give '\xx+' where xx is not 00. Using '\00+' for comparison will work.

Maybe tst is able to give us some enlightning how Hebrew characters are encoded.

In your last post the first and the last diagram will work but the middle one will give a problem with UTF16 characters.

Message Edited by waldemar.hersacher on 11-07-2008 07:38 AM

[altenbach]

---

waldemar.hersacher wrote:

Will this lead to a problem on Asian or other UTF16 characters? Asian or UTF16 characters maybe give '\xx+' where xx is not 00.

---

Sorry, I have no experience with other character sets/keyboards. I only simplified the originally given code for the same outcome, without possibly improving functionality. 🙂

Personally, I would place an I16 indicator on the event terminal, run the VI, press the key I am interested in, and then make it into a I16 diagram constant for guaranteed accurate results. A comment can be placed in the label of the diagram constant. 🙂

Yes, tst might be a better expert here. 😉

Message Edited by altenbach on 11-06-2008 10:48 PM

[TCPlomp]

About checking on key down events I have created an enum with the ASCII character (0-127).

This can be downloaded here, a more thourough explanation is here.

And a screenshot:

Ton

[tst]

When you want to use non-English text, you use a different ASCII code page, which means that the bytes are simply interpeted differently (e.g. 130 means one letter using one code page and another when using another code page). I think the code page affects the entire byte, but I'm pretty sure that the bottom 128 characters are equal for practically all code pages. Hebrew only has 27 letters, so it fits nicely within the high bit of the ASCII standard and when clicking a Hebrew letter you get a value between 129 and 255, depending on your code page. I haven't checked what happens when you enable Unicode support in LabVIEW (which isn't officially supported), but I'm assuming it's the same. You probably want someone who has support for Japanese or Chinese, but I'm guessing it will simply be a value above 255.

In any case, I would also go (and have gone in the past) with the method of creating a constant of the value and using a label for it.

If you want to read more (and read about Bulgarians, Texans and some wimpy Californians [hmm, Alten is from California]), you should read this article.

[tst]

P.S. I'm generally not a fan of using type cast, unless there's a need for it, for fear of using it incorrectly. There are often safer methods.

[altenbach]

Format some booleans requires 16 diagram constants, 8 selects, 32 wires. (or less if done differently)

(seen here)

Message Edited by altenbach on 11-12-2008 08:51 AM

[TCPlomp]

Porting some C code to LabVIEW.

Source:

---

int j = 0; for ( int i = 0; i < G_ReadLen; i = i + 2 )

{

BYTE AD_H = ByteArray.GetAt(i);

BYTE AD_L = ByteArray.GetAt(i + 1);

ValueArray[j] = AD_H << 8;

ValueArray[j] = ValueArray[j] + AD_L;

unsigned long Temp = ValueArray[j] >> 12;

Volts[j] = ((float)ValueArray[j]) * 0.0048875;Message.Format(

"%X , %X - %X, -- %d, +%.3f Volts", AD_H, AD_L, ValueArray[j], ValueArray[j], Volts[j]);

m_output_ep1i.InsertString(0,Message);

j = j + 1;

}

---

Do everything up to unsigned long. Including two indexes, two index array primes (one would suffice), a check for imax (probably the size of the output array).

And use a 'replace array subset' on an empty array.

Or do the easy, false way of telling LabVIEW to read the U8 array as an U16.

as seen here

Ton