"Lock State.Get" this method cannot work rightly when in .exe????

[wen151]

hello everyone ,I just make a test program ,to find if a .vi file is in "password-protected",but I test it when it in vi environment it can word normally,

But after I let it to create an .exe file, this .exe cannot rightly to show the special vi's lock state ,it seems always to show "locked(no password)",it puzzled me!!!

it is the in vi envrionment resaultit is the .exe resaultthe program

[rolfk]

A build VI (Unless you enable the option to keep the diagram for debugging purposes) does not contain any diagrams anymore. Consequently the password protection is meaningless as there is nothing to protect anymore and the Application Builder removes the password protection too during build.

[LucianM]

Yes but if you try to load any VI (not part of a build) with block diagram included, that method will return "Locked (No Password)" even if VI is password protected. Not sure why OP needs this in exe but still, that method does not work as documented.

[rolfk · Accepted solution]

The runtime engine in which an executable runs knew nothing about diagrams and passwords. It got the possibility to serve a diagram over a remote debug connection if present but the function that determines locally if there is a diagram and password does not know about. The code to deal with a diagram and a possible password simply doesn’t exist in the runtime engine. You can report it as bug but it is going to be classified as very low priority.

The question really is what the OP wants to do. Most likely it’s more of an unintended use of that attribute and are there other methods to achieve his objectives much better.

[wiebe@CARYA]

---

@rolfk wrote:

The code to deal with a diagram and a possible password simply doesn’t exist in the runtime engine. You can report it as bug but it is going to be classified as very low priority.

---

A quick, and therefor likely, fix to that bug would be to make the method return an error and to change the documentation to "available in RTE=NO".

[rolfk]

---

wiebe@CARYA wrote:

---

@rolfk wrote:

The code to deal with a diagram and a possible password simply doesn’t exist in the runtime engine. You can report it as bug but it is going to be classified as very low priority.

---

A quick, and therefor likely, fix to that bug would be to make the method return an error and to change the documentation to "available in RTE=NO".

---

Which would be partly lying too! 🙂 But I agree that this function does not make much sense in the RTE since the only option of "no diagram available" isn't really one of the enum choices for this method.

Except of course there are likely a number of NI internal and released tools that will break when this method returns an error 1345 or whatever. While that is not unsurmountable for NI tools as they can rework them before releasing the fixed version, it also can and very likely will break customer tools.