Application builder - Invalid characters in filename

[MOJO_FZJ]

Dear LabVIEW Community!

Please help me, I recently updated to LabVIEW 2024 Q1 and a new PC. After this update the App builder crashes with an error message that a filename in a LLB contains an invalid character:

"The filename (...\*IDN?.vi) entered is either blank or has invalid characters -- \ / : * ? < > | " 

Possible reason(s):

LabVIEW: (Hex 0x41C) The LabVIEW filename is invalid.

The LLB is provided by the device manufacturer and I use it for years without any problems. I wonder, if I'm the only one with this (new?) problem.

Was it just accepted in the past? Do I need to rename all files manually? There are several VIs with invalid characters in several LLBs.

Cheers

MoJo

[Bob_Schor]

The App Builder crashes when you ask it to build something.  The Error Message is clear, and makes great sense -- your Build seems to specify a file whose name has the characters *IDN?.vi , which are clearly not "legal" filenames, and must reside somewhere in your code.  If you can't find these characters by yourself, post (all of) your code and we'll help you look for this misplaced string (looks like a VISA command/response).

Did the code work in an earlier version of LabVIEW?  Have you tried going back to the "earlier version that worked" and seeing what has changed?

Bob Schor

[billko]

---

@Bob_Schor wrote:

The App Builder crashes when you ask it to build something.  The Error Message is clear, and makes great sense -- your Build seems to specify a file whose name has the characters *IDN?.vi , which are clearly not "legal" filenames, and must reside somewhere in your code.  If you can't find these characters by yourself, post (all of) your code and we'll help you look for this misplaced string (looks like a VISA command/response).

Did the code work in an earlier version of LabVIEW?  Have you tried going back to the "earlier version that worked" and seeing what has changed?

Bob Schor

---

Yeah, the OP posted that it used to work in an earlier version.  This sounds like a legacy driver.  LabVIEW must be handling files within an LLB differently these days.  (Although really I am surprised it ever worked.)

[tst · Accepted solution]

I was recently asked by a client to support an old program of theirs. For various reasons we decided to upgrade the code to LV 2024 Q1 and build an EXE to see that the code they gave me actually matches the version of the EXE they're using and that they can run it.

When doing this, I also saw the same issue. I assumed that the project I had was probably simply not the updated version and that in the version that built the EXE there was workaround for this, but now that you asked this question, I guess that this did work and simply stopped working correctly at some version of LV. I do know now that at least the code they gave me is not the most recent version, so it's possible this was handled differently, but is seems more likely that it worked and stopped working.

Anyway, what I did was to add all of the VIs with the invalid names to a virtual folder in the project and then rename them in the  build spec so that they don't include the invalid characters (this is in the "Source File Settings" page). If you do this too, note that the names need to not conflict with other existing VIs.

[MOJO_FZJ]

Hi Bob,

Thank you for your reply. Yes, it worked well in LabVIEW 2016.

I also wondered about the invalid characters in the filename, but because the compilation worked, I didn't think about it any further.

But with LV2024 it no longer works.

The LLB is from 2010 and was shipped on a CD : )

Cheers

MOJO

[MOJO_FZJ]

Hi tst!

Many thanks for your suggestions.

Does it mean, that I need to rename each file by hand?

Why do you suggest to do it within the build spec and not in the LLB itself?

MOJO

[tst]

---

@MOJO_FZJ wrote:

Does it mean, that I need to rename each file by hand?

Why do you suggest to do it within the build spec and not in the LLB itself?

---

I suppose you could write a VI to iterate over all of them and call the Save Instrument method for each VI, but you would still need to decide what to call each of them. In my case, for instance, simply removing the illegal characters would not have worked, because there were already VIs with those names (for instance, something like ABC.vi for writing and ABC?.vi for reading). I only had about ten such VIs, so I just did it manually.

You could change the VI names in the LLB as well, which would make your life easier if you have future builds. I didn't do that because I didn't want to touch the LLB and have to deal with potential consequences (for instance, if we happen to get a newer version of the LLB from the vendor which supplied it, presumably it would still have the original VI names and then we would need to do some relinking).

You could probably also set the LLB as a build destination outside of the EXE and save the VIs there, which will then probably not require renaming, but will requiring having the LLB as another file next to the EXE.

[JÞB]

---

@billko wrote:

---

@Bob_Schor wrote:

The App Builder crashes when you ask it to build something.  The Error Message is clear, and makes great sense -- your Build seems to specify a file whose name has the characters *IDN?.vi , which are clearly not "legal" filenames, and must reside somewhere in your code.  If you can't find these characters by yourself, post (all of) your code and we'll help you look for this misplaced string (looks like a VISA command/response).

Did the code work in an earlier version of LabVIEW?  Have you tried going back to the "earlier version that worked" and seeing what has changed?

Bob Schor

---

Yeah, the OP posted that it used to work in an earlier version.  This sounds like a legacy driver.  LabVIEW must be handling files within an LLB differently these days.  (Although really I am surprised it ever worked.)

---

Serendipity.  I just reminded another poster that LabVIEW.ini has an old token to allow browsing inside LLBs.  The default value is FALSE.  This could be a legit way for the App Builder to have worked in a previous version with the same token value = TRUE. 

[rolfk]

LLBs have almost no restrictions about what characters a filename can contain. Unlike your most beloved OS (no matter which one that is 😁). In LabVIEW 8.0 and earlier the Application Builder created one huge LLB and copied every single VI into it, slapped an executable startup stub in front of that LLB and a little identification trailer at the end and sold you this as a valid Windows executable (other platforms was slightly different but the main principle remained).

This worked quite well until LabVIEW classes and LabVIEW libraries were introduced. As an LLB has no internal file hierarchy at all it can not contain the same file name twice, but that is the exact main characteristic of class overrides and the namespacing of LabVIEW libraries also makes the occurrence of same VI names much more likely. To solve that, the application builder now builds an archive very similar to a ZIP file, then stores it as a user resource inside the executable startup stub and declares this (rightfully) to be an executable. This also made it possible to add an executable signing option, since the executable was now a fully valid Windows executable image file.

While building the ZIP archive, it copies all files referenced by the build specs and any dependencies, into a temporary directory structure on disk before turning that into the ZIP resource and then storing it as a resource in the exe file. This intermediate step of creating temporarily on disk a file hierarchy of the internal compiled VI files, requires all the files to correspond to the naming restrictions on the current OS.

One possibility to avoid that difficulty was to enable the "Use LabVIEW 8.x file layout" option In the Build Spec. But that doesn't work well if your project contains LabVIEW classes and LabVIEW libraries. The Application Builder still works but will create many directories next to your exe to store all the VIs with the same names that can't be put in the internal LLB.

There is actually still a LabVIEW tool in Tools->LLB Manager that allows to browse into LLBs and convert them to directories. It also will warn about naming issues because of invalid characters in file names.

The option to enable browsing into LLBs directly from Windows explorer is long gone. This was enabled through a special Windows shell extension DLL that needs to get installed and registered in Windows. NI released that around LabVIEW 7.0 times, the year after I had released a similar shell extension, but they eventually abandoned that later in LabVIEW 8.21 or thereabout. It has nothing to do with the Application Builder. This was a pure Windows Explorer shell extension and the LabVIEW file manager does not access the file system through the Windows Explorer Shell, but directly through the Win32 file API, which is at least two layers below the Windows Explorer Shell. Accessing the file system through the Explorer Shell interface is an exercise in frustration and a performance nightmare and I can't recommend anyone to build a solution on that. LabVIEW would gain some gimmicks by doing so but it would be nearly unusable and the entire Windows Shell is fully build on DCOM and tends to get sooner or later unstable. Definitely not a well suited thing to handle very large file hierarchies in a more complex way than one directory at a time.