tags:

views:

36

answers:

1

Hi all, I have a MFC application which has its GUI implemented as part of the executable code (view-doc architecture etc.) My application uses some DLLs I worte.

Now I have to write another DLL which I know it has to have a GUI as well.

My question/uncertainty is should I implement the GUI as part of the main application (main GUI) and connect between them OR should I implement a GUI as part of the new DLL and just make an entry point in main GUI ? In both cases it clear to me that I must have an interface class.

In case I implement a GUI as part of the DLL, it is clear to me that the GUI should hold a pointer to the interface class but how should the interface class talk with the GUI (e.g. notifies the GUI a long operation is completed or give the GUI intermediate reports about the operation ? 1) using pointer from Interface to GUI? 2) using message loop with callbacks? 3) other options???

Many Thanks

+2  A: 

Generally, MFC + GUI stuff in DLL = much needless trouble. At least as I recall from ten+ years back. It has to do with MFC Microsoft-style "support" for something or other that someone at Microsoft imagined could be a problem, so MFC distinguishes between different kinds of DLLs and DLL states and whatnot, in particular with regard to resources.

So I'd say, for MFC, keep the GUI stuff in the main program, if at all practical.

It also has to do with allocation of responsibilities. By separating responsibilities you get a more clean design that is easier to maintain. Put knowledge of things where it's needed for the responsibilities.

Cheers & hth.,

Alf P. Steinbach
Agree. Managing resource states between the DLLs and the EXE in MFC is headache inducing.
demoncodemonkey
+1 - keep all GUI in main - redesign the DLL interface so it is separate from GUI - this is a good idea anyway, separating GUI code from "real" code leads to more re-use of the "real" code.
Jeff
Frankly I don't care about difficulties with separate GUI.I just care for good design and good coding practice.
David
Suppose I separate GUI code from "real" code - How should I notify the GUI when something is change? I don't want to use callback as they are not object oriented.Does 'Observer' design pattern is good idea ?
David
@David: Separation and good design is one and the same. :-) MFC already has some support for a simplified Model-View-Controller (see the Wikipedia article on that), its `CView` and `CDocument` classes. I don't like MFC's version but if doing an MFC app I'd go with the flow, so to speak. In your DLL you'd do something similar to `CDocument`, or perhaps even a `CDocument`-derived class. Check the documentation about MFC-specific things (e.g. see `AFX_MANAGE_STATE`).
Alf P. Steinbach