04-07-2010 08:10 AM
Jeff Bohrer wrote:
- Boolean Case structures that use the output of Comparision (e.g. = functions) are not self-documenting and are always rube-goldberg code! Note that I use the value as the case selector.
Since you are looking for hex values, also remember to change the radix of the case selector to hex - this is one I commonly forget that also improves readability. I'm sure you knew that - but it's easy to forget when you have, as you pointed out, much more glaring style problems.
04-07-2010 08:22 AM
JackDunaway wrote:
Jeff Bohrer wrote:
- Boolean Case structures that use the output of Comparision (e.g. = functions) are not self-documenting and are always rube-goldberg code! Note that I use the value as the case selector.
Since you are looking for hex values, also remember to change the radix of the case selector to hex - this is one I commonly forget that also improves readability. I'm sure you knew that - but it's easy to forget when you have, as you pointed out, much more glaring style problems.
Huh- You Know, I never tried to do that before. Thanks for the tidbit!
04-07-2010 08:34 AM
Do you ever code someting, and on the way-home that day figure out how to do it better... I mean, waaaay better? That's what we call a way-homer around here. Well, I fixed up a Ruby I created yesterday reeeal good this morning based on a way-homer:
This is a little utility that converts a string of charmap Unicode codes to LabVIEW's MBCS Unicode encoding. The first method has the string display set to Normal, and the second method is set to Hex. The new way natively groups the byte couples, capitalizes the hex numerals, and filters non-hex keystrokes. Did I mention it runs faster also???
04-07-2010 09:56 AM - edited 04-07-2010 09:57 AM
Wait. What?
You can change the radix of a case selector?
That I did not know.
Cool.
Shane.
04-07-2010 09:58 AM
Wait. What? Again.
LabVIEW and Unicode?
Did I miss something here?
Shane.
JackDunaway wrote:
This is a little utility that converts a string of charmap Unicode codes to LabVIEW's MBCS Unicode encoding. The first method has the string display set to Normal, and the second method is set to Hex. The new way natively groups the byte couples, capitalizes the hex numerals, and filters non-hex keystrokes. Did I mention it runs faster also???
04-07-2010 10:08 AM
04-07-2010 10:53 AM
smercurio_fc wrote:See here.
I tried to reply as a comment to that blog post when it first came out, but had trouble embedding this picture. Apparently the Communities require a hosted image, and it cannot even paste an image from your account's picture gallery. Well, I'll post the image and my comments here, and link from the Community Page.
If you want THE ABSOLUTE ULTIMATE PSYCHEDELIC EXPERIENCE OF RUBENESS then start using Unicode in LabVIEW. It will do crazy things with your mind and your code. Check out what happened to one of my projects (this has happened 3 times in the past year and a half):
And periodically (every few weeks or so for the past year and a half?) I will open a block diagram and it looks like this:
And I got a message box like this (this has happened twice in the past year and a half):
Those things were obviously undesirable, and happened with no warning. I just opened the project, and whaddaya know, Unicode Attack on the entire IDE. If you're ever using Unicode and this happens, shut down LabVIEW immediately and DON'T SAVE, and exit the Getting Started window. Open back up, and hope the problem is gone - it usually is gone 75% of the time or so. If a second restart doesn't help, you may need to revert to the repository.
I cannot make this disclaimer large enough: Unicode is REALLY not officially supported by LabVIEW. You had better keep a darn good code repository, because twice the entire project has been "Attacked by Unicode", where the only solution is reverting back to the repository. (I have been attacked in 8.2.1, 8.6.1, and 2009.)
Although Unicode Attack episodes are undesirable, serendipity jackpot! I now have successfully harvested a Unicoded Tree, Enum, and Ring. (You can normally only have Unicode in strings, labels, captions, listboxes, and MCL's).
One other thing: set the UseUnicode=True in your INI true ONLY long enough to set up a few controls/indicators with Unicode, then delete that key. Apparently (lamely), tip strips are supposed to disappear when you have that flag on (full conversation here).
Woes aside, we have successfully used LabVIEW to create an application where you can change languages on the fly, and Unicode coupled with LabVIEW is a powerful combo. It's a little frustrating to "learn the ropes", and it's not as bad as I make it out to be (if you love your repository, it will love you), and it's certainly worth your while for the sake of internationalization. Finally, a shameless plug for Better Unicode Support.
04-07-2010 11:10 AM
For one moment I thought, you want it to look like this 😉
Excellent work.
04-07-2010 11:30 AM
04-07-2010 11:32 AM
Guenter Mueller wrote:For one moment I thought, you want it to look like this 😉
Excellent work.
No, those images of my IDE were very undesirable. I wanted my application internationalized, not my IDE! My guess is that somewhere, somehow, dark in the LabVIEW IDE underpinnings, a bit got flipped that controls whether text is interpreted as 1 byte ASCII or 2 byte MBCS. The display I would expect would display N 1-byte characters, and the Unicode Attacked display would display N/2 2-byte characters. I could never reproduce a combination of actions that would "flip that bit", so I could never teach the old LabVIEW dog the "Unicode thyself" on command trick.