Skip to content

Conversation

ciozi137
Copy link

Summary

This PR addresses Issue #90 by making process name matching case-insensitive to align with LabVIEW's behavior when recognizing overrides.

Problem

LabVIEW recognizes overrides regardless of case (e.g., both Process.vi and process.vi are valid), but our current implementation was case-sensitive. This mismatch could cause issues when process names didn't exactly match the expected case.

Changes Made

  • GetCallingProcessCloneName.vi: Updated to perform case-insensitive matching for Process.vi names
  • WaitOnProcessSync.vi: Modified to use GetCallingProcessCloneName.vi for consistent process name resolution, ensuring the same matching algorithm is applied during both registration and synchronization
image image

francois-normandin and others added 3 commits January 10, 2022 09:11
- Change GetCallingProcessCloneName.vi to be agnostic to Process.vi case (match on Process.vi or process.vi)
- Change WaitOnProcessSync.vi to call GetCallingProcessCloneName.vi to ensure same match algorithm as was used to register the process
@Tom-McQuillan
Copy link
Contributor

In principle I am supportive of this.
Although, I am curious why P/process.vi would be spelt differently.
Is it common to create the process vi without using the template tool?

@ciozi137
Copy link
Author

@Tom-McQuillan good question. I'm not sure why I ran into this problem. Maybe I had created 'process.vi' and dropped in the template:
image

Maybe I temporarily renamed it 'DoNotRunProcess.vi' for some other debugging purpose and then inadvertently renamed it 'process.vi' when I switched back.

The main point is that LabVIEW doesn't recognize a difference and wouldn't, didn't, alert the user if the case didn't match. So hoping to save someone else in the future.

I don't know if there is a more elegant fix available instead of:
481616869-16798093-6fb2-4216-84d0-e710b09e71b6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants