WaitOnProcessSync.vi expects Process.vi not process.vi

[ciozi137]

Describe the bug
If Process.vi is named process.vi (lowercase 'p'):

• LabVIEW will not mind that a dynamic dispatch method has a child override with a different case
• The SMO framework will create and start the process without error
• Error will be thrown during shutdown during WaitOnProcessSync.vi (WaitOnProcessSync.vi does not look for Sync Notifier at startup)

To Reproduce
Steps to reproduce the behavior:
1. Use Process.vi:

*** 2. Rename Process.vi to process.vi***

• TestLauncher returns the following error:
  • SMO.lvclass:WaitOnProcessSync.vi:4400004
    is not a valid process name
    Complete call chain:
    SMO.lvclass:WaitOnProcessSync.vi:4400004
    TestSMO.lvclass:process.vi:5310001
    SMO.lvclass:LaunchProcess.vi:3770001
    SMO.lvclass:LaunchProcess.vi.ACBRProxyCaller.58F00179

Source?

[ciozi137]

@francois-normandin this is a little more complicated than I thought. Making the following change to the Match Pattern filter causes WaitOnFinalProcessSync.vi to hang forever if (if I'm using process.vi):

[francois-normandin]

lvclass:[pP]rocess.vi ??

[ciozi137]

You would think, but it hangs here if the VI is called 'process.vi':

[Pp]rocess.vi worked fine for 'Process.vi'. I think there must be something going on upstream where the Sync Notifiers are created. I will dig in more.

[ciozi137]

'GetCallingProcessCloneName.vi': Making this change here seems to fix the issue:

[ciozi137]

Since LabVIEW apparently allows any case for the override method, how about we use 'To Lower Case' to take care of all cases for all letters:

[Tom-McQuillan]

For what it's worth, I am in favour of the to lowercase solution since it's the simplest to read

[ciozi137]

This probably isn't worth obsessing over?

[Tom-McQuillan]

The top one with a to lowercase on both strings. again just to make it obvious to the developer what is happening.
But yes, doesn't need obsessing over, it's just a process of being mindfull when making changes