LabVIEW Embedded/ARM with password = Crash to Desktop

Question

Hi,
I just installed the LabVIEW Embedded for ARM evaluation kit with the LM3S8962.
A basic project will compile and download perfectly.  (Amazing how well this works!)
However, as I'm primarily a SW dev, I am a firm believer in GOOP and other OO technologies.  I can create the class and call it in the main VI, but when I go to compile the project, the compiler asks me for the password to a deeply embedded VI (which I do not have) and, after failing to validate or canceling, LabVIEW will just disappear.
If I create and use a native LVOOP class, it'll compile and run, however pass-by-value is simply not an option.
Test Cases:
1) Naked Main VI: compiles, runs OK
2) Main VI calling protected VI: will not compile if VI remains locked ('cancel' button or invalid password entered) and will sometimes CTD
3) Main VI calling LVOOP class: comples, runs OK
4) Main VI calling GOOP class: CTD after OK/Cancel in password dialog
Versions:
Windows XP 32bit Professional SP3
LabVIEW 2009 9.0f1 Evaluation
Endevo GDS 3.51
This really looks like an issue with password-protected VIs.
Has anyone seen this sort of problem before?
Thanks,
Tony
P.S. Will try to attach to another post since the forums keeps giving me an error when posting with attachment...

Answer 1

Claire,
I understand why the builder asks for the password.
I also understand that the LabVIEW Application Builder does not ask for the password, it instead compiles the VI into the Runtime bytecode whether password protected or not.
If this is indeed the case, then the LabVIEW Application Builder generated bytecode could then be used to "expose the functionality of the VI."
However, that's just not the case. 
If you've ever looked at the C code generated from a single VI, then you might understand that the C code is in no way understandable or recognizable as to what is really happening in the VI.
I guess if you personally worked on or made great contributions to the LabVIEW runtime engine you might possibly - with no small amount of time and effort - be able to gain some small understanding of what's going on in the generated C code.  However, for the average (or even advanced) C programmer, it's obfuscated to the point of incomprehensibility.
I've attached the C code generated from the Naked VI for reference.  It's 45Kb of structures, lookup tables, and functions that - while they do perform what the VI does - are in no way recognizable as a while loop, a couple shift registers, addition nodes, split/join number nodes, and VI calls.
While, on the surface, that answer seems plausible, I'm afraid it is indeed nonsensical.  Perhaps I could have a chat with the person making this decision?
Thanks for your time,
Tony
Attachments:
Main_VI___Naked.c ‏45 KB