Why Does LabVIEW VI Property Path Keep Stale Folder Case?

Opening the subordinate VI before the main VI makes the VI Property path reflect the folder’s current letter case. The number that matters is load order: when Main.vi loads SubVI.vi first, LabVIEW can retain the folder spelling recorded by the caller even after a case-only rename.

Symptom and operational impact

The reported layout places Main.vi in C:\temp\ and SubVI.vi in C:\temp\SubVI\. Initially, each VI’s Path property returns the expected location. Rename only the folder from SubVI to subvi, close LabVIEW between tests, and then open Main.vi. The subordinate VI’s Path property can continue to report the old capitalization.

On a case-insensitive Windows file system, both spellings can resolve to the same directory, so the VI may load and execute normally. The defect becomes operationally significant when the returned string is passed to a case-sensitive repository, compared as case-sensitive text, used on a case-sensitive volume, or transferred to a UNIX or case-sensitive macOS environment. File identity and path-string identity are separate tests.

Item	Observed quantity or state	Decision limit	Where to read it
Physical folder spelling	C:\temp\subvi\	Must match the spelling expected by downstream case-sensitive processing	File-system directory listing
Returned VI path	May retain C:\temp\SubVI\	Any character-case difference is a mismatch for a case-sensitive comparison	Path output of the VI Property node
First VI loaded	Main.vi or SubVI.vi	SubVI.vi first avoids the reported symptom	Controlled startup sequence
Reported defect identifier	48188CE8	Use the complete identifier when contacting NI	NI bug record reference

Load-order mechanism

This is state and timing, not file access. LabVIEW resolves a referenced VI as it loads the caller and creates an in-memory VI object. The Path property then exposes the spelling associated with that loaded object. A case-insensitive file system can accept the stored spelling even when the directory entry now uses different capitalization, so successful loading does not prove that the returned path string matches the directory’s current case.

Opening SubVI.vi directly changes which path spelling establishes the in-memory object. When the subordinate VI is loaded before Main.vi, LabVIEW discovers it through the renamed directory and the stale-case symptom does not occur. If Main.vi performs the first resolution, its saved reference can supply the older spelling. Closing LabVIEW between trials matters because an already-loaded VI can preserve session state and invalidate the comparison.

The report was made with LV8 and suggested that other releases exposing the VI Path property might behave similarly. Treat the installed LabVIEW release as a test variable: run the same clean-session sequence on every version used for development, build, or deployment.

Approach comparison

Approach	Result	Best use	Limitation
Open Main.vi first	Can return the former folder capitalization for the subordinate VI	Reproducing the defect	A successfully loaded VI can hide the string mismatch
Open SubVI.vi first	Returns the renamed folder spelling in the reported test	Immediate development workaround	Requires control of startup or load order
Normalize case in application logic	Can make comparisons pass on a chosen case-insensitive system	Comparisons where case is intentionally irrelevant	Destroys meaningful case information and can mask portability defects
Validate against the file system	Detects disagreement between the property string and directory spelling	Repository, packaging, migration, and deployment checks	Detection alone does not refresh the loaded VI object

Use direct subordinate loading as the immediate workaround because it addresses the observed load-order trigger without rewriting the path. Add file-system validation when the path crosses into a case-sensitive tool or platform. Avoid relying only on forced lowercase or uppercase conversion; that changes the string but does not establish the canonical spelling of every directory component.

Controlled reproduction procedure

1. Create or use Main.vi in C:\temp\.
2. Place SubVI.vi in C:\temp\SubVI\ and call it from Main.vi.
3. Read the Path property for both VIs and record the complete returned strings.
4. Close LabVIEW so neither VI remains loaded.
5. Change only the directory’s letter case from SubVI to subvi.
6. Start LabVIEW and open Main.vi, without first opening SubVI.vi.
7. Read the subordinate VI’s Path property. Compare the string character by character with the directory spelling.
8. Close LabVIEW again, reopen it, and open SubVI.vi before Main.vi.
9. Read the same Path property and compare the result with the preceding trial.

Keep the directory location and VI files unchanged between the two load-order trials. Otherwise, a relink, search-path change, or second copy of the VI introduces another variable.

Workaround implementation

1. Perform the case-only directory rename while the affected VIs are closed.
2. Start a fresh LabVIEW session.
3. Open the renamed subordinate VI directly from C:\temp\subvi\SubVI.vi.
4. Open Main.vi only after the subordinate VI is resident in memory.
5. Read the Path property and use that verified value for repository, packaging, or migration operations.
6. Repeat the clean-session test after saving, moving, or relinking either VI.

If an application loads VIs dynamically, make the same ordering explicit in its startup logic: resolve the target VI from the intended directory before loading a caller that contains an older path spelling. Where load order cannot be controlled, compare the property result with the actual directory entry and stop the case-sensitive operation when they differ.

Verification and recurring pitfalls

Verification requires both resolution and textual checks. Confirm that the returned path reaches the intended file, then compare every directory component using case-sensitive string equality. A file-exists result on Windows proves reachability only; it does not prove portable path spelling.

1. Restart LabVIEW to clear session-dependent load state.
2. Run the subordinate-first sequence and capture its Path property.
3. Run the main-first sequence in another fresh session and capture the same property.
4. Compare both strings with the file-system spelling, preserving case.
5. Repeat on each LabVIEW version and target file system used by the project.

Common test errors include opening

SubVI.vi
FAQ

How do I reproduce the LabVIEW VI Property Path bug?
Rename C:\temp\SubVI\

to C:\temp\subvi\, close LabVIEW, then reopen Main.vi without opening SubVI.vi first. Read the subordinate VI’s Path property and check whether it still contains SubVI.