DQMH: PPL Class Conflict

[mibo0691]

Dear community,

i have a big DQMH based framework. For some of the modules i extended the DQMH Message Queue classes' functionality by creating a child class "Message Queue Override.lvclass" inheriting from the original Delacor message queue class. I stored the code insid a lvlibp that is part of the main project. All methods in there are Dynamic Dispatch except the "Create Message Queue" method because it does not have an object input connector.

Now i want to cut out certain DQMH modules from the main project, put each in a dedicated git repo to manage fixes and updating globally, having a PPL build spec each of their own, and the framework projects that implement / use those modules only take the packed library as dependency. This requires that i also do this with the DQMH Messag Queue override i wrote, because my DQMH modules rely on that override.

So i moved the original lvlib containing the override class and code into a dedicated lvproj and built a PPL from it.

Now in the main project, if i replace the legacy lvlib with the lvlibp and fix caller dependencies, i get a class conflict breaking everything. The error window only tells me that both refnums are members of a class hierarchy, but there is neither a simple up cast nor type cast. (second screenshot). It seems that LV is unable to detect that the override class from the lvlibp is a child class of the original DQMH class. When clicking on a dynamic dispatch VI that offers parent and child method, however LV properly displays the selection window asking which implementation i'd like to open up.

Does anybody know what i'm doing wrong here?

I have other PPLs in non-DQMH projects that inherit from each other, with no issues so far.

[dkfire]

I think you have run into the same problem that Actor Framework users have. 

Is the DQMH framework build as a PPL ?? 

If no, then every time you build a DQMH module / override class into a ppl, it will take the parent class and all needed dependencies into the PPL, and your class will reference that build-in parent. This is because the ppl has its own namespace. 

To get around that, you need to build the DQMH framework into a PPL and then reference the classes in that PPL. 

Then all your PPL build modules will reference the same class from the same name space. 

[mibo0691]

Dear dkfire,

thanks a lot for your hint. The DQMH framework is not built as PPL at the moment.

I guess i could find out how to do that. But the question to me is, does this work? Because most of the functionality of DQMH is executed with scripting processes and the access takes place from the LabVIEW runtime menus, i doubt that this can be done with a ppl in memory. Or maybe it would be neccessary to replace all DQMH function calls from a newly scripted module, with the calls of the PPL ...