Invoking other Modules from C++ ...

[David Raphael]

So I was getting ready to add an automatic screen stretch to my image acquisition module, and I realized that there is no obvious way for one module to invoke another's methods...

This is easy enough to do in PJSR, but I think this presents a problem since each module is loaded at startup.  They don't have visibility to each other.  This is a classic late binding problem I think.  There would need to be some sort of registry I could access to check what is available for invokation...

Am I thinking of this correctly?  Is it impossible for me to invoke another module directly from my module?

Thanks,
Dave

[Nocturnal]

Indeed you ran into an issue I brought up quite a while back, probably in relation writing a PCL module for image stacking. I imagined that module would need to load existing modules including their GUI components and let the user interact with them. Alternatively I'd want modules to push their GUI components into a different window so you could effectively combine several modules into one without having to re-write the entire GUI for each module. Perhaps PCL 1.7 has a mechanism to deal with this.

[Carlos Milovic]

Hi David

The source code of the STF process is avalaible as an example, whitin the PCL files. There is no problem if you copy functions from there.

[David Raphael]

Yep :-) 

Already did that...

just figured I'd try not to duplicate code.

/d

[Juan Conejero]

Hi David,

This is easy enough to do in PJSR, but I think this presents a problem since each module is loaded at startup.  They don't have visibility to each other.

Unfortunately this still isn't possible in version 1.7.0. We call this feature intermodule communication (IMC). It is already implemented and working extremely well for file format modules (ImageCalibration, ImageIntegration, StarAlignment and many other tools are using it). However, I still haven't had the time to implement IMC for processes. I intended to implement it for 1.7.0 but the project functionality took me more time than expected, IMC is very complex, and achieving a stable 1.7.0 release before Summer was an absolutely priority. IMC for processes is one of the next priority tasks so It will be implemented during the 1.7 cycle, that is during Q4 2011.

For now, don't hesitate to reimplement things. If you need an auto STF, just copy and paste the relevant code from the IntensityTransformations module. Keep in mind that this is a temporary situation; once we have IMC for processes working we'll get the same flexibility in PCL that we have now in PJSR.

Alternatively I'd want modules to push their GUI components into a different window so you could effectively combine several modules into one without having to re-write the entire GUI for each module.

This is indeed very desirable and it will be implemented as part of IMC for processes, both in PJSR and PCL. I am sure that you can figure out the complexity involved in this feature. Keep in mind that these functionalities can compromise stability of the whole platform. A defective implementation can be a real nightmare instead of something useful. If you know me then you know that I won't release such a significant feature until I am 100% sure that my implementation works correctly and won't cause problems.

[Nocturnal]

Right, I have doubt that this is difficult to do but it is a restriction that makes the modularity of PI a liability rather than a virtue. It makes implementing a full stacking pipeline tedious despite the fact that all components are there, for example. That's why, at the time I questioned the wisdom of implementing all those stacking related features separately instead of as a single process. Well, I questioned it in my mind anyway