Call functions in parent from a runtime loaded DLL
egra...@yahoo.com
I am developing a 'plugin' for a MFC-based GUI. The plugin is also
MFC-based, and is a simple dialog. The plugin is loaded at runtime --
i.e. the DLL is not linked and no .DEF file is used. The user
specifies the location of a plugin.
The plugin needs to call function(s) in the main application. Can this
be done? I can pass a pointer to the main application to the DLL.
However, how do I tell the linker that calls like:
parent->CallFromDll
are not undefined but will be available at runtime?
Thanks
Ajay Kalra
news:1156471416.3...@m73g2000cwd.googlegroups.com...
> Hello,
>
> I am developing a 'plugin' for a MFC-based GUI. The plugin is also
> MFC-based, and is a simple dialog. The plugin is loaded at runtime --
> i.e. the DLL is not linked and no .DEF file is used. The user
> specifies the location of a plugin.
>
> The plugin needs to call function(s) in the main application. Can this
> be done? I can pass a pointer to the main application to the DLL.
You can do this if the main application has exported the methods. Typically
the app will expose its functionality thru an object model using automation.
You will then use COM to access that functionality. It all depends upon the
application for which the plugin is being written. What app is it? Does it
have an object model?
--
Ajay Kalra [MVP - VC++]
ajay...@yahoo.com
David Ching
news:uzqMBx%23xGH...@TK2MSFTNGP05.phx.gbl...
> You can do this if the main application has exported the methods.
> Typically
> the app will expose its functionality thru an object model using
> automation.
> You will then use COM to access that functionality. It all depends upon
> the
> application for which the plugin is being written. What app is it? Does it
> have an object model?
>
COM automation could be overkill for a simple plug-in that only works with
one app. A much simpler system is to pass abstract base class interfaces:
*** NOTE: this is pseudo code, so ignore any syntax errors and focus on
the intent!
Say the DLL exports a function called
BOOL "C" __declspec(dllexport) InitPlugin (IMainApp *pMainApp);
where IMainApp is an abstract base class:
class IMainApp
{
public:
virtual void CallFromDLL() = 0;
virtual void CallFromDLL2() = 0;
...
};
And the main app implements the interface:
class CMainApp : public CWinApp, IMainApp
{
...
// IMainApp
virtual void CallFromDLL();
virtual void CallFromDLL2();
}
Then the main app inits the plug-in, e.g.
CMainApp::LoadPlugins()
{
HINSTANCE hLib = LoadLibrary ( _T("theplugin.dll") );
InitPluginFunc = GetProcAddress (hLib, _T("InitPlugin"));
InitPluginFunc (this);
}
Now the plugin has this nice IMainApp interface to call it's host
application. To reciprocate, InitPlugin() could be changed to return an
IPlugin, an interface for the main app to call the plugin:
(IPlugin *) "C" __declspec(dllexport) InitPlugin (IMainApp *pMainApp);
Interfaces like this let you avoid exporting entire classes and the need to
make sure compiler and version settings are the same between app and
plug-in, etc. You get the benefit of using classes, just like COM objects,
but without the pain of GUID's, the registry, threading models, and all that
complexity you don't need considering you don't need system-wide components.
-- David
http://www.dcsoft.com
Ajay Kalra
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:dNuHg.2839$yO7....@newssvr14.news.prodigy.com...
> "Ajay Kalra" <ajay...@yahoo.com> wrote in message
> news:uzqMBx%23xGH...@TK2MSFTNGP05.phx.gbl...
>
> > You can do this if the main application has exported the methods.
> > Typically
> > the app will expose its functionality thru an object model using
> > automation.
> > You will then use COM to access that functionality. It all depends upon
> > the
> > application for which the plugin is being written. What app is it? Does
it
> > have an object model?
> >
>
> COM automation could be overkill for a simple plug-in that only works with
> one app. A much simpler system is to pass abstract base class interfaces:
This has nothing to do with what is right or wrong. It *all* depends upon
the app for which the plugIn is being written. You are assuming the OP
controls the app and the plug in. The app may not export anything or
anything meaningful or provide any header file. It may not even be written
in C++. You cannot control what the app should do unless you are the one
writing the app. In that case, its really not a plug in but simply a generic
module in the project.
A good example would be Excel as the app and you are writing an AddIn. You
as a addin writer have nothing to do with excel's code. This is how
PlugIn/AddIns are defined. All the communication with the host app is done
using Automation (COM). I dont know how OP has the set up.
David Ching
>
> This has nothing to do with what is right or wrong.
That's right, it doesn't. It's another alternative to your suggestion,
that's all.
-- David
Ajay Kalra
I thought I tried to explained that its not an alternative. There is no
CWinApp in the main app or MFC for that matter or C++. Essentially there is
no access to app source for plugin writers that includes header files. You
typically program thru a type library which has pre-defined interfaces,
events, enums etc.
David Ching
>
> I thought I tried to explained that its not an alternative. There is no
> CWinApp in the main app or MFC for that matter or C++. Essentially there
> is
> no access to app source for plugin writers that includes header files. You
> typically program thru a type library which has pre-defined interfaces,
> events, enums etc.
>
I don't understand the issue here. The OP said, "I am developing a 'plugin'
for a MFC-based GUI". Given this, the scheme I proposed is valid and much
lighter weight than COM automation. I'm not saying you should never use COM
or automation, but neither would I use it as a first choice unless simpler
schemes wouldn't work for one reason or another. The OP can determine if
that's the case and act accordingly.
-- David
Ajay Kalra
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:D6wHg.10897$%j7....@newssvr29.news.prodigy.net...
If I understood your suggestion, you proposed modifying source of main
application. For a plugin developer, this choice is typically not available.
David Wilkinson
Ajay:
Yes, if you cannot control the application code you have to make do with
what is provided. But if you can, I agree with David that a non-COM
abastract interface is the way to go. I do it exactly the way David
says, with multiple inheritance (with the MFC base class in the
left-most position).
David Wilkinson
Ajay Kalra
> what is provided. But if you can, I agree with David that a non-COM
> abastract interface is the way to go. I do it exactly the way David
> says, with multiple inheritance (with the MFC base class in the
> left-most position).
>
How is this possible? The only way this is possible is if you control
the main(host) app. How can you do this for example in Excel? What you
are saying is the way to go but its just not possible in a PlugIn
unless the host application supports it.
---
Ajay
David Ching
>
> How is this possible? The only way this is possible is if you control
> the main(host) app. How can you do this for example in Excel? What you
> are saying is the way to go but its just not possible in a PlugIn
> unless the host application supports it.
>
The wording of the original question left open the possbility that the OP
was designing the plug-in system for both the app and the plug-in. If so, I
put forth an idea that has advantages over the standard "use COM". If the
situation matches the OP's, they are free to use it. If not, good luck with
the hassles of COM.
-- David
Ajay Kalra
> was designing the plug-in system for both the app and the plug-in.
I did not assume that. If you have control over what main app is, you
can treat it like another module in a project. But thats not how you
design a plugin. Keep in mind that plugins developers are not
necessarily C++ developers. For a plugIn, you always communicate thru
COM. Main reason for that is the support of other language(s) besides
C++, eg VB.
I have no idea how the setup is. After developing/designing
PlugIn/AddIns for over 3 years, I gave my input as how it is done in
commercial world. COM is tough and convoluted but thats how PlugIns are
developed in all major applications, including Office, IE etc.
---
Ajay
David Ching
> I did not assume that.
Well, the OP did say, "I can pass a pointer to the main application to the
DLL," implying he had controlled the app/plugin interface.
> If you have control over what main app is, you
> can treat it like another module in a project. But thats not how you
> design a plugin. Keep in mind that plugins developers are not
> necessarily C++ developers. For a plugIn, you always communicate thru
> COM. Main reason for that is the support of other language(s) besides
> C++, eg VB.
>
> I have no idea how the setup is. After developing/designing
> PlugIn/AddIns for over 3 years, I gave my input as how it is done in
> commercial world. COM is tough and convoluted but thats how PlugIns are
> developed in all major applications, including Office, IE etc.
>
Well, Microsoft has this agenda to make it easy for VB programmers whereever
possible. To achieve that, they designed this icky thing called COM and
made it extremely difficult for C++ programmers to be productive. Since
this is an MFC group and we don't have to assume to have anything to do with
VB, there are other plugin approaches that cater to C++ programmers better.
In fact, I designed one based on the description I provided, and it is now
shipping millions of copies.
To the OP: I guess by now you are sick of our going back and forth over the
merits of COM vs. a more C++ approach. Please use the one more appropriate
to your situation.
Thank you,
David
Tim Ward
>
> I did not assume that. If you have control over what main app is, you
> can treat it like another module in a project. But thats not how you
> design a plugin. Keep in mind that plugins developers are not
> necessarily C++ developers. For a plugIn, you always communicate thru
> COM. Main reason for that is the support of other language(s) besides
> C++, eg VB.
Er, no. I have a similar setup - MFC application, want to develop plug-in
DLLs. The application currently exports nothing using any technology, so
*regardless* of what technology I want to use (C++ "interfaces", COM, CORBA,
anything else) I *will* need access to the source code of the application
(which I've got, so that's fine).
The plug-ins will also be in MFC and *will* necessarily be written by C++
developers, being in C++. There's no way my client will allow me to go to
all the hassle and expense of building a COM system if I don't need it, as I
don't. As I suspect the OP is, I'm looking for a C++ way to do a C++ job.
(You might ask: if I'm building the plug-ins at the same time as the
application in the same development environment, why bother with plug-ins at
all? Simple - some customers will have some features, some will have others,
the DLLs won't get shipped to the people for whom they are not relevant.)
--
Tim Ward
Brett Ward Limited - www.brettward.co.uk
Tom Serface
I don't think David was making any assumptions. He was only offering up
another idea based on a possibilty that wasn't clearly spelled out in the
original post. I thought it was interesting. Frankly, I'd stay away from
COM for trivial stuff whenever possible especially if I have control over
all of the components of the applications and they are mostly single (or
low) use.
Tom
"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:1156512842.6...@i3g2000cwc.googlegroups.com...
Ajay Kalra
> developers, being in C++.
Thats the key here. You are forcing it to be written in C++. I did not
make this assumption.
> There's no way my client will allow me to go to
> all the hassle and expense of building a COM system if I don't need it,
Thats fine. There is nothing wrong in it. Keep in mind that none of the
major commercial products do it like this.
> As I suspect the OP is, I'm looking for a C++ way to do a C++ job.
I have no idea what OP is doing. If you read my first response, you
will find that I recommended what you have suggested. Usng Automation
was sited when OP does not control the source.
---
Ajay
Ajay Kalra
> possible. To achieve that, they designed this icky thing called COM and
> made it extremely difficult for C++ programmers to be productive. Since
> this is an MFC group and we don't have to assume to have anything to do with
> VB, there are other plugin approaches that cater to C++ programmers better.
> In fact, I designed one based on the description I provided, and it is now
> shipping millions of copies.
I think I did not make myself clear enough. It has absolutely *nothing*
to do with VB. Nothing. If OP is writing a PlugIn for an app which has
an object model, OP *HAS* to use COM unless the application exports
what OP needs OR OP controls the source of the host application. That
means if OP is using MFC for a IE/Office/Autodesk PlugIn, OP will be
using COM. There is no choice.
I did not assume that OP was the plugIn developer as well as the main
application developer.
---
Ajay
David Ching
OK, we get it! :-)
-- David
Ajay Kalra
> OK, we get it! :-)
>
<coughing> Mission Accomplished.....
---
Ajay
Tom Serface
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:8SFHg.12855$kO3....@newssvr12.news.prodigy.com...
egra...@yahoo.com
entirely clear.
I have control over both the calling application and the plug-in DLL
code. The calling application has a number of functions that I want to
call. I guess I could send them to the DLL one at a time by passing
the function pointers to a function exported from the DLL.
However, I'd like to 'import' the functions in the calling application
from the DLL.
Can I used the 'GetProcAddress' to get at functions in the calling
applications? What would I used for the handle?
Thanks,
Eugene.
Ajay Kalra
egray...@yahoo.com wrote:
> Thank you all for the various suggestions. My original post was not
> entirely clear.
>
> I have control over both the calling application and the plug-in DLL
> code. The calling application has a number of functions that I want to
> call. I guess I could send them to the DLL one at a time by passing
> the function pointers to a function exported from the DLL.
>
> However, I'd like to 'import' the functions in the calling application
> from the DLL.
>
> Can I used the 'GetProcAddress' to get at functions in the calling
> applications? What would I used for the handle?
>
Why use GetProcAddress? Since you have the app and the plugIn, just
export the methods from the app and import these in PlugIn.
---
Ajay
Joseph M. Newcomer
.DEF files have to do with the construction of the DLL, not its use, so I have no idea why
you would be concerned about the .DEF file.
Doing callbacks in C++ is very hard, and generally not worth doing if you can avoid it.
What is "CallFromDll"? WIthout knowing the data types involved, it is impossible to tell
what is going on here. However, there is no way to call a method in a callback class
unless it is static. My attitude has been "why bother?" Callbacks generaly represent an
old paradigm of thought, applicable to some low-level APIs (and many of those are done so
badly they are nearly unusable), but trying to call C++ methods of a class is generally
such a wrong approach that you shouldn't even bother.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm