Modularizing Help

[Aaronov]

I was told I should probably ask this here, even though it relates to MFC, it is probably more a design question. So, At my workplace we have a number of programs (sub systems) which make up our software. Some of these programs need functionality from other programs and I'm trying to find a good way to perhaps modularize each program so that common code/resources can be used "globally". The current example forcing me to find a solution is the need to launch a dialog from our Accounting package from another sub system. The big problem is that this is quite a large dialog and depends a lot on things from the Accountings MainFrame. I was thinking that for each sub system I could create a DLL which contained common dialogs, etc that could be used by other programs. The problem I face is that a lot of the dialogs have dependencies on their parent programs MainFrame and I'm not sure how to get around it. I guess one solution might be to take everything out of the MainFrame and put it into its own class which can then be passed to the DLL.. but I don't even know if that would work as I still need to Initialise this new class the same way it would be done in the parents program, but now in the other sub system.. though in saying that the DLL should probably be responsible for setting itself up. Your thoughts? Cheers

[Lost User]

Aaronov wrote:

I was thinking that for each sub system I could create a DLL which contained common dialogs, etc that could be used by other programs. The problem I face is that a lot of the dialogs have dependencies on their parent programs MainFrame and I'm not sure how to get around it.

That will depend on the type of dependency. If it's an enum that get's shared, move it to another library that both the DialogDll and the ParentProgram can access. That could also be done for customized buttons and UserControls - if those have been designed with a separation of UI/data. It it's data that the dialog depends on, I'd suggest using some kind of IPC with the ParentProgram, or calling a webservice that interacts with the ParentProgram's datastore.

Aaronov wrote:

though in saying that the DLL should probably be responsible for setting itself up.

Can I translate that to "the class inside the assembly is responsible for constructing itself?"

I are Troll :suss:

[Aaronov]

Yep, that translation is correct. The code that is moved from MainFrame into a class in the DLL is responsible for setting itself up. The dependencies are mostly just basic variables, enums, etc so I think it will work by moving them into a DLL. What's an IPC?

[Richard Andrew x64]

Aaronov wrote:

What's an IPC?

Inter-Process Communication Pipes, mailslots, memory-mapped files.....