Mr Mike

I'm no longer with NI (as of 2014!), but I just got notification on this thread. I'll forward it to someone who's still there and ask them to respond.

Hello LAVA, I left NI about 9 months ago, but LabVIEW is on my resume, so hear from recruiters occasionally. I got a flurry of calls and emails from recruiters yesterday and today searching for a LabVIEW developer. One said it was contract work, one said it was for a full-time position. The position is in Spring, TX, which really only points to one company. They specifically asked for no telecommuting, so you've got to be in the Houston area, or willing to relocate. Let me know if you're interested by replying or private messaging and I'll send your contact information to the recruiters. - Mike

In case anyone stumbles on this, this more name documentation here.

I took a quick look over it. I removed the write before the property node reads because I thought it might be doing some priming that wasn't necessary. I also made all of the loops use a shift register to use the same object the whole time, instead of copying it each time. Finally, I made every VI read or write four times instead of just once, so that the differences in timing could compound and be more noticeable. It looks like the property nodes are 8% slower. I haven't looked at these tests with a critical eye (or a properly caffeinated eye), but that's about what I'd expect. I bet if you included the same error checking as the property node the difference would be closer. I hope you're coming to the LAVA BBQ I was under the impression that issue had been fixed. I filed CAR 484048 to our performance team. They'd still not be uninlinable if they were dynamic dispatch.

I was under the impression that all the linking issues with LVOOP property nodes had been resolved. I haven't seen a CAR on that at least since 2012. Admittedly, LVOOP property node CARs are handled by someone else now, but they usually come to me to review fixes for any serious issues. I was silently following this thread to see if anyone else had anything to say about Jack's comments about LVOOP property nodes. The case sensitivity CAR is an interesting one. I hadn't seen it yet. Sorry it was a pain for you. About the case structure issue. Yes, there is a second case structure that gets inserted, but it's set up so that it defaults to the no-error case, which means it operates very quickly. I haven't tested it thoroughly, but I don't think it makes a significant difference on performance. You can also turn on the the "Ignore Errors Inside Node" option to remove a case structure on the calling VI. And you can remove the case structure from the property implementation VI. BONUS: I'll buy a (free) beer at the LAVA BBQ to anyone who writes a test that shows a big difference in performance between property nodes and subVIs. Consider whether the subVIs are inlined, too. I reserve the right to judge what a big difference is. To be clear, the factors to consider are: 1) Ignore Errors Inside Node, 2) Case structure in property accessor, 3) Inlined accessor VI or not. You immediately forfeit your right to a beer if some crucial part of your code gets dead code eliminated. Competition ends August 4, 12pm CDT. Really the only purpose of this is to settle the question once and for all.

Wow. Lots to respond to here. You can also pass in floating point numbers, but be careful: LabVIEW uses the IEEE 754 round-to-nearest even integer rule when rounding numbers that end in .5. 102.5 rounds to 102. 70.5 rounds to 70. 71.5 rounds to 72. Also, the behavior changed in LabVIEW 2010. To Upper Case, To Lower Case, Octal Digit?, Decimal Digit?, Hexadecimal Digit?, White Space? and Printable? all allow you to wire in a numeric. According to their documentation, those nodes evaluate the numeric as the ASCII character corresponding to the numeric value and in all other cases return FALSE. In LV 2009, they return false for any value over 256. In LV 2010 and later they return true for some values -- corresponding to the proper return value for the lowest 8 bits. E.g. LV 2009's White Space? primitive returns true for Int32(10) -- the line feed character -- and false for Int32(266). In LV 2010 it returns true for both. I'm usually the loudest complainer about people treating strings as a byte arrays. In most programming languages, strings are not bytes arrays. In some languages, for legacy reasons you can treat them as byte arrays. In LabVIEW they are byte arrays. That results in interesting things with Multibyte Character Sets. I don't have any of the Asian localized LabVIEWs installed, but I think strings in those languages will have a string length reported as twice the number of characters that are actually there. When you have the unicode INI token set, this is definitely the case. Arguably that's wrong, but there's no way to go back and change it now. I couldn't agree more to your first three paragraphs, but I've got to disagree about the difficulties. The platforms which are supported is entirely related to the language and compiler for that language. Any time -- absolutely any time -- strings move from one memory space to another (shared memory, pipes, network, files on disk) the encoding of the text needs to be taken into account. If you know the encoding the other application is expecting, you can usually convert the text to that encoding. There are common methods for handling that text that doesn't convert (the source has a character that the destination doesn't have), but they're not perfect. The good thing is that it'd be extremely rare since just about everything NI produces right now "talks" ASCII or Windows-1252, so it's easy to make existing things keep working. What you're talking about is how the characters are represented internally in common languages. In C/C++/C# on Windows they're UTF-16. In C/C# on Unix systems they're UTF-32. As long as you're in the same memory space you don't need to worry. There is no nightmare. Think of your strings as sequences of characters and it's a lot easier. As soon as you cross a memory boundary you need to be concerned. If you know what encoding the destination is expecting you encode your text into that. If/when LabVIEW gets Unicode support, that will be essential. Existing APIs will be modified to do as much of that for you as possible. Where it's not clear, you'll have the option and it'll default to Windows-1252 to mimic old behavior. Any modern protocol has its text encoding defined or the protocol allows using different encodings.

Does anyone have some code they'd be willing to send to NI that replicates this issue? Or detailed steps to reproduce?

I don't have an answer for you, but I just wanted to point out that string constants would be scrambled in a part of the VI. It'd be hard to see the encryption key -- you'd need to know what part to get out, how to get that part, and how to unscramble it -- but it's not there in plain text. If that's suitably secure for you, then go for it. But I'd recommend against it

Just to let everyone know, I've notified a few people at NI about the problem. I'm not sure who to contact within NI, but I contacted people who probably know who to contact. Mike B National Instruments R&D

After what I've read in this thread, I think there may be a bug here. I've filed CAR 440207 to investigate this behavior. I'll update this thread when I hear more information. While I understand and appreciate hoovah's sentiment that you should just trust the compiler, I think that blindly trusting it is not always the best idea. There's a lot that can go wrong. It almost always does the right thing. And it reflects well on LabVIEW that you trust it so much. But sometimes it doesn't do the right thing. It's important to look at LabVIEW with a critical eye sometimes.

Definitely not sarcastic. It was entirely sincere. Your older posts didn't include the warning at first and you edited them to include it. Now you're including it by default. Thank you. What each flag does is confidential. About a third of the flags are for edit-time features (like "object is grayed" -- but that's just a side effect of what the flag actually does), a third for settings on objects, and another third for flags for the compiler. That's all I'll say about it.

Thank you for being much more explicit about the dangers of playing with these things. I'd be especially careful with 0x0000 00010, 0x0000 0080, and 0x0000 4000. Different types of objects have different sets of flags stored in the same place. Good luck. You're probably going to be seeing a lot more strange behaviors once you start playing with non-controls. And they're not good strange behaviors

You're right. It's in Vision. I got bit by the same mistake 2 weeks ago and I thought I had memorized which is where.

You can use the NI-IMAQ package for decoding barcodes. I'm not 100% sure about Code 39 (frequently called 3 of 9), but I know it can decode QR codes.

I would think it would have sent. If you can get me the report ID (the GUID in C:UsersYourNameDocumentsLabVIEW DataLVInternalReportsLabVIEWVERSION) corresponding to the crash, I can look it up. just having the log file doesn't let me look it up.

Did you submit the crash report? The minidump that comes with that is insanely helpful. If not, can you attach it? It's in: C:UsersYourNameDocumentsLabVIEW DataLVInternalReportsLabVIEWLabVIEWVersion on Windows 7. You can figure out the path on other OSes. A quick glance at the log doesn't give me anything immediate, but someone will take a deeper look if this gets filed as a CAR. I'd need steps to reproduce and the minidump to file it as a CAR.

And don't forget to post the CAR number in this thread!

The documentation for Format Into String says that you can use escape codes in the format string. (Search for "Use special escape codes")

No problem. If it makes you feel better, I kudo'd the original idea.

An unofficial response: avoid this primitive. It was requested by a group within NI and it turned out they didn't need it halfway through its development. In a lot of cases it can create a compile error. In some cases it will cause a crash on save. The author says that it was never thoroughly tested (so don't expect IEEE 754 conformance!) and that bug reports for it are rejected since it was never officially released (not even for internal use). This is a prime example of digging around in LabVIEW and finding fool's gold instead of actual gold.

This CAR has been fixed in LV 2013. The fix should be in LV 2013 Beta 2. MikhaelH: If you're part of the beta program, you can download the LV 2013 Beta 2 and test it out. If not, PM me and I'll send you a link to sign up and my email address to get you into the beta program.

Both FrontPanelWindow:OSWindow and FP.NativeWindow are in the Run Time Engine. They are not in RT (Real Time). - Mike

This is wrong. Generally speaking, in the US: Violation of copyright is something that a person does and they get in trouble with the government (fine or jail). Breach of contract is something you do and you get in trouble with the other party (you get sued for monetary damages). Both are illegal even though the person bringing the complaint (the district attorney or the other party) is different and the punishments are different. Unfortunately, it's not yours. I personally believe it should be, but that's not the way software licensing works. It's not the way the software world works. We gave you a copy of LabVIEW and you (most likely depending on what your license agreement says) have a intangible copy of it -- whether it's bits on your hard drive or on a CD -- and we grant you the right to use it for so long. It's never your property. I think it's absurd but that's how it works.

Haha...I completely missed that...I just read the text of the post.

I've shortened quotes for sanity and added parenthesized numbers after statements to indicate what I'm replying to where. Yeah, it is kinda silly that people expect miracles from it. That's why in 2012 we added this to the password dialog: And why we published Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams. And why we continue to openly state that it is circumventable and only provides as much security as a locked door -- a determined intruder will get in due to the nature of a house. You want the homeowner to be able to get in a house and open the windows. You want LabVIEW to be able to get into the VI and open the block diagram. You can break the window or use a battering ram, or you can use the key. NI made this clearer in 2012, though no amount of warnings or papers will be enough for some people. That's why it's silly for people to rely on that. But just because they weren't smart/motivated enough to protect themselves does not give you the right to break in. Open source is great and I'm a huge fan. I've been running various flavors of Linux exclusively for 9 years. And I'm a software engineer. I realize that although great things come out the FOSS community, it is very very very hard to make a living off of FOSS software. Most FOSS software doesn't have a large enough user base (or code base) to make money purely off of support. You need to pay for software sometimes because that's how the technology industry works. We software engineers need to be paid, too. If you're only looking at VIs and not misusing the contents (plagiarizing source code, redistributing, stealing) then I don't think there's much harm. However, I think there is harm in immediately releasing information on how to break password protection because other people will misuse it. You are not the only user. LabVIEW is obeying a different user and disobeying you. Why should LabVIEW disobey a different user and obey you? Just because it's your computer doesn't mean you gain rights over other people. You choose to run LabVIEW. If a parent tells a child they can't have ice cream before bed, that doesn't mean the can have ice cream before bed in someone else's house. This was probably on the order of 1/10000th the effort put into LabVIEW 2012. We don't only have a duty to develop features important to customers, but also to continue to support older features important to customers, even if the feature isn't perfect and cannot be. Don't throw out the baby with the bath water. Although ShaunR opened with a bit of a dig that really blunted his message, I think he's definitely got the right message. flarn2006, check out Responsible Disclosure and a quick list of companies with Responsible Disclosure policies. Although NI doesn't have one, we have worked within the general framework of responsible disclosure with many people. If you'd like more of an assurance, I can try to find something for you. Finally, even if you're helping NI, it's probably not going to make us significantly more money. It might not even make us money. But you will also be helping customers by helping ensure customers have a more secure application. You talk like you're fighting a battle for the proletariat, the unwashed masses of LabVIEW users, against NI. In reality, we're pretty open to playing ball as long as you don't make it a pain.