Strange dynamic dispatch behavior on NI Linux RT (PXI)

[APolk@BW]

I am migrating a relatively large project from PharLap on PXIe in LabVIEW 2019 to NI-Linux RT on PXIe in LabVIEW 2020.  Prior to the migration, I've been running the same project for about 6 months and have not seen this issue.

In short, when calling a dynamic dispatch method, the child class is calling the parent method instead of the child override method. I am not seeing this issue in other parent/child combinations in the same project, and I don't see this issue with the exact same code in LabVIEW 2019 on PharLap. I tried mass compiling last night and there is no change in behavior.

As a brief example, I have attached a simple project with parent/child/grandchild classes that yields correct behavior. The parent class contains a template method which does not write any data.  The child class does not have an override method.  The grandchild class has an override method which sets the parent data = true.  When cast to more generic class, the grandchild still calls the correct method, yielding data = true.

In my case, the exact same parent/child/grandchild hierarchy is present, and I have simplified the functionality inside the child class to only write a single boolean data value in the parent class just like the example project. However, the parent method is called instead of the override method and therefore the data is not written. 

My thought is that a missing dependency/broken VI/Linux incompatibility is somehow causing this issue behind the scenes, but is not presenting as a broken VI.  Anyone have any ideas on what to look for?

[APolk@BW · Accepted solution]

The answer is that Linux is a case-sensitive file-system and Windows isn't. 

If the parent template method is "action.vi" and the child override is "Action.vi", the override will work on a windows machine, but will not on the linux target.

I have updated my example project to reflect this. Not sure if this is intended behavior, or if a CAR exists, but it certainly caused me a headache.

[Jacobson-ni]

There is actually Bug 790573 filed for this behavior. It also mentions that if the method is set to must override in class properties, the class will be broken if the cases don't match (although call parent method can still link to that method).

You usually wouldn't have to worry about this because creating a new VI for override would give the correct name. I'm guessing someone probably came in later and wanted to change the capitalization of method names to keep to some particular style guidelines but only updated one of the classes.