Application builder name collision detection is not case insensitive

[Jim Kring]

[status: Reported to NI]

Steps to Reproduce

1) Create a project

2) Create two classes, Class1 and Class2 (these should be siblings with LabVIEW object as their parent)

3) In Class1, create a method named "MyMethod.vi" (observe case sensitivilty -- only the M's should be uppercase)

4) In Class2, create a method named "mymethod.vi" (observe case sensitivilty -- all letters should be lowercase)

5) Create a build rule for an EXE that has both "Class1.lvclass:MyMethod.vi" and "Class2.lvclass:mymethod.vi" as startup (top-level) VIs.

6) Build the EXE

Observed Results

The build will fail with Error 1357: "A LabVIEW file from that path already exists in memory, or exists within a project library already in memory".

Expected Results

No errors

Analysis

I believe that the algorithm that LabVIEW uses to detect and avoid VI name collisions, prior to the build, is case sensitive and not catching the fact that "MyMethod.vi" and "mymethod.vi" cannot occupy the same location on disk (on MS Windows, at least).

Workaround

Ensure that all methods with the same name have the same case.

Example Project

Download File:post-17-1193708527.zip

[Jim Kring]

Update... Status: Confirmed by NI R&D, CAR Number 4ETCH790

[eaolson]

QUOTE(Jim Kring @ Oct 29 2007, 08:42 PM)

I believe that the algorithm that LabVIEW uses to detect and avoid VI name collisions, prior to the build, is case sensitive and not catching the fact that "MyMethod.vi" and "mymethod.vi" cannot occupy the same location on disk (on MS Windows, at least).

This is also true for two regular VIs, at least in my 8.20 version, application builder and LVOOP notwithstanding. (I'm not sure if that's what you meant in this sentence or not.) If MYVI.vi is open, you can't open myvi.vi.

[Jim Kring]

QUOTE(eaolson @ Oct 30 2007, 02:09 PM)

This is also true for two regular VIs, at least in my 8.20 version, application builder and LVOOP notwithstanding. (I'm not sure if that's what you meant in this sentence or not.) If MYVI.vi is open, you can't open myvi.vi.

> If MYVI.vi is open, you can't open myvi.vi

Actually, that's not true, in this case. Since these VIs are members of seperate classes/libraries, their names are scoped/prefixed with the class name. So, it's perfectly fine to have them in memory together. They simply cannot be stored in the same folder (or inside the same LLB/EXE) on disk. This is the heart of the problem. LabVIEW starts the build process, but fails to detect that there will be a name collision on disk, during the build. The build progresses and then fails.

Thanks,

-Jim

Update: I was just informed by someone at NI that the http://wiki.lavag.org/CAR' Number" title='LabVIEW Wiki article on CAR Number' alt='Wiki article on CAR Number' style="border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">CAR Number is actually 4ETCH79O -- it ends in a the letter "O" (as in Owl), not the number "0" (zero).

[eaolson]

QUOTE(Jim Kring @ Oct 30 2007, 04:42 PM)

Actually, that's not true, in this case. Since these VIs are members of seperate classes/libraries, their names are scoped/prefixed with the class name. So, it's perfectly fine to have them in memory together. They simply cannot be stored in the same folder (or inside the same LLB/EXE) on disk. This is the heart of the problem. LabVIEW starts the build process, but fails to detect that there will be a name collision on disk, during the build. The build progresses and then fails.

Oh, that's right, I forgot about class/library namespace. I'll just go sit in a corner and be quiet now...