Packaging multiple DQMH modules in a PPL? What about nesting modules?

[DoctorAutomatic]

If I recall correctly, about 6 months ago I was working on a project of about 5 DQMH modules. This project was itself a part of a larger overall project. I tried putting all my DQMH modules inside the "main" DQMH module (the one with the API that the larger overall project would interact with) and all hell broke loose. I mean it "worked" but it seemed to ruin any ability to create new events using the DQMH menu.

I'm going off of memory here. Should that have caused such problems or is there likely something wrong with my DQMH installation?

If that's not the recommended way to put multiple modules together, what is? Could I just create a new empty LV module and place all my DQMH modules inside at the same level? Will that mess any of the scripting tools up?

An additional question is how would I hide some of the public API vis that are used between my sub modules but don't want to be accessible from outside my multi-module PPL? Is wrapping in a single parent library and making them private ok to allow siblings to still use or will that not work? Do I have to make all my modules friends of every other module and use community scope? If I go into module A's properties, add module B and C as friends, do I also need to add module A to the friends inside the properties of B and C? You can see how this would be lots of clicking and risking forgetting one or two.

Thanks. 

[Darren]

The DQMH Scripting Tools do not support putting module libraries inside of other module libraries. And more generally, this was not a use case that was ever considered when the framework was designed.

Why do all your modules need to be in a single PPL? Just for the community scoping issue you describe? For maintainability purposes, a PPL per module would be much easier to work with, and I've seen other DQMH developers be successful with this approach.

If you want to restrict your public API VIs to only being called by certain modules, then it's no longer a public API. 🙂 For code readability purposes, I feel like you would need to set the community settings on the libraries as you describe, but also add a wrapper API that defines the specific community-scoped request VIs you want to make available for friends of the library to call.