C++/How to Seprate the views of an MDI application into different DLLs?
Actually i've an idea to develop a MDI application into different DLLs, means i need to use 1 MDI form to call 2 different DLLs..you have any idea for developing this??
This appears _not_ to be a C++ question but a MS Windows development question (albeit probably using C or C++). C++ (as in the ISO/ANSI C++ standard) does not support such things as dynamic link or shared object libraries - hence any support is specific to the compiler (or range of compilers) and of course depends on the underlying support for such entities by the operating system. You do not mention either the operating system or the compiler you are using. I shall assume you are using and MS Windows Win32 based system, and suspect you may be using a MS VC++ compiler with MS libraries - possibly you are using the MFC but you do not say.
Remember there are many operating systems and many compilers and developments systems and many libraries and frameworks that can be used by people asking the likes of me questions - I may not guess correctly from other information in a question so it is best to mention such things specifically. Also more detail on exactly what your specific difficulty is will get you a more specific (and hopefully relevant and shorter or more detailed) answer.
As it is I think you may either have misstated the question or are doing something more complex than the question implies - implies to me that is. So this is going to be a quick few hints over a few DLL topics in the hope than one of them may fit what you are trying to achieve.
You state that you have (or will have) an MDI (child window) form that "call 2 different DLLs". What do you mean by "call 2 different DLLs"?
I read this to mean that it calls functions (possibly class member functions) from 2 differing DLLs. So what is the problem, think I on reading this - just make sure the functions / classes are properly exported from the called DLLs and imported into the calling DLL or EXE. See for example the documentation on the MS VC++ specific dllimport and dllexport storage-class attributes in the MSDN library (which may be found online at http://www.msdn.microsoft.com/library
I am also assuming that although you are using DLLs you are using them 'statically' - that is you rely on linking against their import libraries.
Of course if you are doing something weird like trying to split the implementation of a single class across two DLLs then don't!
Of course the other thing you may be trying to do is load the DLLs dynamically at run time using LoadLibrary or similar. If you are using classes exported from a DLL then this may pose a problem as you will most likely have a great difficulty matching a class instance's member functions to the function pointers from the loaded library. One idea (from the Symbian OS as it happens) that neatly gets around this problem is to export a single C function from such a DLL called something like MakeInstance or MakeMyObjectInstance or MakeMyInterfaceInstance - which returns a new instance of a specific type, which can be a class. The class pointer returned is either a pointer to a specific class type or a base interface type - should you require loading various different implementations of the same component type. Of course you could have more than one such factory function in a dll - each returning a different object type. If you require a more robust component scheme then you are drifting into COM territory. (again check out the MSDN library for information on COM - and good luck it is quite a large subject, so you may also like to get hold of a few books on COM if you choose to go down this path).
The other use of DLLs that you might be referring to is as resource only DLLs - for example for different locales, in which the correct resource DLL is loaded for the user's current regional settings. Note that you have to specify the HINSTANCE (or HMODULE - the documentation is a bit fuzzy on the use of these handle types) of the loaded library when requesting resources (using Win32). The MFC/ATL often helps by trying to obtain the HINSTANCE of the DLL or EXE the resource is in for you - however one presumes this comes at the cost of the time needed to search for the correct HINSTANCE value.
If this does not address your problem or you require further details then please post a follow-up question with more detail on exactly what you need to know, and what you are doing, were you are starting from (what the project is structured like at the moment for example) and what APIs, libraries or frameworks and what compiler(s) you are using (raw Win32 API, MFC, ATL, managed code with .NET and Windows Forms etc. etc.; Visual C++ 6, 7, 7.1, other compiler etc. etc.).
If you need an overview of Win32 DLLs then see Dynamic-Link Libraries under Platform SDK: DLLs, Processes, and Threads in the MSDN Library.