Invoking MFC exe methods from MFC Extension dll

[zuhrs]

How can I invoke the methods of an MFC exe from an MFC Extension dll.

A third party aaplication will be invoking the MFC Extension dll. So from the dll I need to invoke the public methods of the MFC exe application. How can it be acheived?

Thanks in advance.

[VictorN]

You need to #include the header file with declarations of exported functions and add the .lib file to the list of objects/libraries modules used for linking.
.lib file is automatically generated while creating the dll.

[zuhrs]

Thanks for the prompt reply

I have done this steps before itself. I mean I had added the lib file in the linker and included the header file also.

Below is the piece of code where I am facing problem.
CTestApp *pISL = new CTestApp; //CTestApp is the exe to be launched and I need a pointer to its //member functions
pISL->calculateTot();

The above piece of code gives a linker error as follows
error LNK2001: unresolved external symbol "public: __thiscall CTestApp::CTestApp(void)" (??0CRBSTApp@@QAE@XZ)



In the exported exe I have the methods as follows:
__declspec(dllexport) CTestApp();
__declspec(dllexport) virtual BOOL InitInstance();
__declspec(dllexport) void calculateTot();



But the following code compiles properly
CTestApp *pISL;
pISL->calculateTot();

Can I know what is the problem in this. I mean I am not able to craete an object/instance of CTestApp.

[zuhrs]

CTestApp *pISL = new CTestApp (); //This line crashes on runtime
CTestApp is an exe actually.

Can I know the solution for this. Thanks in advance.

[VictorN]

1. Just debug it and see why...

2. Why do you create your App class in a dll?

[Eri523]

Looks like what you need is a callback. An .exe application can't expose functions like a DLL does.

[zuhrs]

Thanks for the prompt replies.

Actually I need to get the methods of exe exposed for Inter Process Communication. From the dll I need to launch the particular exe and access its public methods for some automation.

[Eri523]

Actually I need to get the methods of exe exposed for Inter Process Communication. From the dll I need to launch the particular exe and access its public methods for some automation.

Now that sounds like a job for COM.

However, in contrast...

A third party aaplication will be invoking the MFC Extension dll. So from the dll I need to invoke the public methods of the MFC exe application. How can it be acheived?

"Third party application" means you can't modify it, doesn't it? So you can't expose anything that isn't exposed already. If the app has a COM interface, perhaps that provides what you need, if not...

OTOH, if you can modify the app, you can as well modify it to register a callback with your DLL which is sufficient to call app functionality from the DLL. If you need to be able to call functions across process boundaries, you'll need COM again. But now, in this scenario, of course you can add any functionality you want to the app. Note, however, that COM is much more complex than a simple DLL interface (and it's nothing I, myself, am really fluent on).

[zuhrs]

Actually I have the following scenario
1. Application1 Exe developed in some programming language
2. Application2 Exe developed using MFC
3. MFC Extension Dll which is used to communicate between these two processes for IPC

I need to have some option in Application1 so that I can launch Application2. Since they are created using different languages, we need a dll to communicate between the 2 Processes/Applications

I am able to link the Application1 with the MFC Extension dll. But I am struck with using the dll to launch the Application2 and getting the methods of it exposed.

[Eri523]

That sounds like you intend to use the DLL as some sort of "communication hub" between the two apps. I once tried something like that myself and had to learn this: A DLL is always mapped into the address space of the process that links to it. Linkig to the same DLL from two simultaneously running processes does not allow objects managed by the DLL to be shared between the the distinct processes. This is the reason why COM in-process-servers can be implemented as DLLs, while out-of-process-servers (AKA local servers, that would be needed for IPC purposes) can't.

So, if you want to implement a communication hub as a COM server, I'd say you would need to implement it as a third EXE instead of a DLL. And at least if there are just two "endpoint apps" involved, I don't see why they shouldn't directly communicate with each other via COM.

Launching another app shouldn't be a problem in any relevant programming language, and given the language provides COM support at all, I think it should always be possible to get the two to talk to each other that way. IMO that's one of the core reasons why COM was created in the first place.

Of course there are several other IPC options besides COM. Here's an overview: http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx

[Igor Vartanov]

Since they are created using different languages...

Yeah, since the languages are different, MFC extension dll is not an option.