There is some callback granularity missing for declaring static dependencies which we be solved by adding two virtual callback methods, before and after "SMO.Start Dependencies.vi".
Additional context
This is needed to allow more control over the creation/ownership of static dependencies that are common to a base class which can be called recursively where those dependencies need to be shared resources but that should be private to a composition hierarchy. It also would come in handy when merging collections of objects at declaration time or to configure objects by-reference between creation and start of the dependency. Currently, there is no way to control the creation order if A depends on B and C, and B also depends on C. SMO's natural order of execution would be to:
Create A
A creates B
A create C
A starts B
A starts C
Start A (dependencies all started)
But if B also depends on C (i.e a shared resource, but using dependency injection instead of shared resource flag), the current implementation will result in a different composition tree and execution order:
Create A
A creates B
B creates C
B starts C
A creates Cprime (different than C)
A starts B
A start Cprime
Current workaround is to use Attributes or to have a starter SMO that creates the dependencies and injects them when properly called. Problem with those approaches is that you cannot have a part of the system generate the dependencies if they are run as top-level app in a different setting that the full production code. (i.e running a subsystem as top-level for development purposes... system is not there to inject the resources, so need wrapper code to reproduce, which is an annoyance).
There is some callback granularity missing for declaring static dependencies which we be solved by adding two virtual callback methods, before and after "SMO.Start Dependencies.vi".
Additional context This is needed to allow more control over the creation/ownership of static dependencies that are common to a base class which can be called recursively where those dependencies need to be shared resources but that should be private to a composition hierarchy. It also would come in handy when merging collections of objects at declaration time or to configure objects by-reference between creation and start of the dependency. Currently, there is no way to control the creation order if A depends on B and C, and B also depends on C. SMO's natural order of execution would be to:
But if B also depends on C (i.e a shared resource, but using dependency injection instead of shared resource flag), the current implementation will result in a different composition tree and execution order:
Current workaround is to use Attributes or to have a starter SMO that creates the dependencies and injects them when properly called. Problem with those approaches is that you cannot have a part of the system generate the dependencies if they are run as top-level app in a different setting that the full production code. (i.e running a subsystem as top-level for development purposes... system is not there to inject the resources, so need wrapper code to reproduce, which is an annoyance).