Re: Adding plugins to my application
From: Maarten Wiltink (maarten_at_kittensandcats.net)
Date: 05/27/04
- Next message: Craig: "XML Base64 -> File"
- Previous message: J French: "Re: Adding plugins to my application"
- In reply to: Tom: "Adding plugins to my application"
- Next in thread: Jamie: "Re: Adding plugins to my application"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 27 May 2004 09:06:31 +0200
"Tom" <lala@lolo.com> wrote in message
news:c935f1$nul$1@aphrodite.grec.isp.9tel.net...
> Here is what I want : I have a main application that deals with files,
> and I would like it to be able to call some plugins depending on the
> file type (extension). Then regarding the type, the good plugin will
> be loaded, and I would get back some text and a data stream that I
> would use in the main app.
>
> Is there an esay way to do this with dlls ? I didn't manage to find a
> simple yet good tutorial on the web. If someone could explain me a bit
> how it works, or point me out to a good resource...
Perhaps not exactly simple, but elegant - which is to say beautifully
simple when you manage to see through all the regretfully required
details.
The thing to recognise is that the host application defines the plug-in
interface, and all the DLLs offer functionality through the same shape
of keyhole.
I think I wrote a fairly long post about plug-ins here a few months ago;
Google should have it.
Asuuming you can locate and load the right DLL, your problem reduces to
sending it a filename and getting back a string and a stream (TStream?).
This is the basis of your plug-in interface: the DLL should export a
function that transforms these parameters into these output values.
So you just require your DLL to export
function MakeUpABetterNameThan"DoWork"
(const Filename : String;
const ReturnData : TStream ): String; stdcall;
I included the stream as an object passed in because returning newly
allocated objects from functions is bad form (now is not the time to
discuss the reasons for this). The DLL can just write to it, and you
can read from it after it returns.
The string return value would not be my first choice; I've learned
to return integer status codes: zero for success, any other value,
preferably negative, for errors. (There's only one way for something
to succeed, but there are usually many ways to fail.) But as long as
you can determine success or failure from it, it doesn't matter all
that much.
It's a good habit to force the calling convention in cross-module
code, and stdcall is the de facto standard.
Groetjes,
Maarten Wiltink
- Next message: Craig: "XML Base64 -> File"
- Previous message: J French: "Re: Adding plugins to my application"
- In reply to: Tom: "Adding plugins to my application"
- Next in thread: Jamie: "Re: Adding plugins to my application"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
