Please help me out with Loading DLLs on the fly !

[Kevin]

Hi,


I have a little problem; i'll try to explain :)


I have created an application, which is compiled as normal EXE file.

In the future it must be possible to add modules to the application, that will be automatically loaded, when placed in a directory.

You can compare it with Winamp and how he loads his plugins: When they're in a directory, they're loaded.


My problem is, that i haven't got the foggiest idea how to accomplish this. I know how to load a function from a DLL, like the API calls to kernel32 or something.

But now i want to Load a dll when the program sees it in the directory...


Please help me out!

By the way, I'm using Visual basic 6.0


Thanx in advance

Regards,

Kevin.

[kevin]

Hi,


I have a little problem; i'll try to explain :)


I have created an application, which is compiled as normal EXE file.

In the future it must be possible to add modules to the application, that will be automatically loaded, when placed in a directory.

You can compare it with Winamp and how he loads his plugins: When they're in a directory, they're loaded.


My problem is, that i haven't got the foggiest idea how to accomplish this. I know how to load a function from a DLL, like the API calls to kernel32 or something.

But now i want to Load a dll when the program sees it in the directory...


Please help me out!

By the way, I'm using Visual basic 6.0


Thanx in advance

Regards,

Kevin.

[Vinayak Sapre]

Just to answer your question using LoadLibrary for regular DLL & CoCreateInstance for COM Dll. But that's automatic in VB. If you call a function from regular DLL or create instance of any class in COM DLL, VB will loadit.


Plugins idea looks good and fancy but this is what I feel. Just by adding servers(DLLs) , client can't become intelligent to use them. So you might want to decide if DLLs are available at a later date how client will use them. A simple solution could be client is inteligent from day one to use all future functionality with a fallback arrangement. i.e. if functionality is not found (as server / interface not available) client will try simpler functionlity, something that is available today.

Other probability is DLL will have everything in it. Client will call one well defined function to give control to DLL which will do the job later (similar to spawing another exe)

[Chris Eastwood]

Hi


I used to work for a WorkFlow software house where we used to do this kind

of thing all the time.


The idea is quite simple but you MUST design your application very carefully

to take advantage of this ability.


The way I implemented it was this :


1. Your EXE has a list stored somewhere (eg. INI file, Registry, database etc)

of externally creatable components (activeX dll's) -when you add a new component

to the system, you update this list in the installation.


2. Your EXE (or another component included with your system) would declare an interface which can be Implemented by other classes (now's a good time to

learn about the 'implements' keyword in VB5/6).


The design of this interface is the most important part - you need to get it right from the start, or you'll have a maintenance nightmare on your hands.


3. Your EXE will read the list of creatable components from the registry and using the defined interface, create those components at the appropriate time (eg. a button click, a predefined event, etc)


A typical interface might be something like :

(class - myComponent.cls)


Public Sub InitConnection(xx as xx) ' whatever you want to pass in


End Sub


Public Sub SetupParameters(xx as xx, xx as xx ... you get the idea)


End Sub


Public Sub DoSomething()


End Sub


Public Sub TerminateConnection()


End Sub


Now, each of your new ActiveX DLL's that you'd create to be an 'addin/plugin' to your system would implement this interface so that your main EXE could create

and call procedures inside it in a standard way - if you break the interface,

you break everything else. The new Component can work however it chooses, as long as it implements this interface in a class you can keep some control over how it works.


We used to pass in a reference to our components of the main EXE, in that way, the external DLL could then control the main exe as well.


It's pretty powerful stuff if (and I can't state this enough) you design it

properly.


Regards


Chris Eastwood

Codeguru - the website for developers

http://www.codeguru.com/vb

[Kevin]

Chris,


I think we both talk about the same thing, but i guess what you explained is

much more than i really need (or not, i can't quiet figure out what to do)


This is exactly what i want...


The main program, with it's basic functionality, can run with or

without extra plugins.


Now a new lpugin is installed in the directory.

On next start, the main program must detect its presence.


Now comes the issue: The dll does not contain any objects of some kind

(like an extra button or whatever). De DLL just contains some code.

This code will do a proces on some input vars and give some output.


The Public function it contains, let's say


Public Function DoYourThing(input vars...) as output type


...


End Function


(That's the way a function for public use in a dll is created, isn't it?...

if not, forgive me for being stupid and explain it plz :)


Every plugin will contain this Function.

So the only thing the main program needs to do is to detect if the DLL is there,

and then ...?... how do i access its function?


I know how it works when you already know the name of the DLL, you just put a


Declare Function DoYourThing Lib "plugin.dll" (Byval input as string) as string


in your (Declarations) part of a module.


I'm browsing the MSDN libraries for help, but it gets very complicated, so...


Can you explain it further to me? an example (if you have) would be great too!...


Regards,

Kevin.

[kevin]

Chris,


I think we both talk about the same thing, but i guess what you explained is

much more than i really need (or not, i can't quiet figure out what to do)


This is exactly what i want...


The main program, with it's basic functionality, can run with or

without extra plugins.


Now a new lpugin is installed in the directory.

On next start, the main program must detect its presence.


Now comes the issue: The dll does not contain any objects of some kind

(like an extra button or whatever). De DLL just contains some code.

This code will do a proces on some input vars and give some output.


The Public function it contains, let's say


Public Function DoYourThing(input vars...) as output type


...


End Function


(That's the way a function for public use in a dll is created, isn't it?...

if not, forgive me for being stupid and explain it plz :)


Every plugin will contain this Function.

So the only thing the main program needs to do is to detect if the DLL is there,

and then ...?... how do i access its function?


I know how it works when you already know the name of the DLL, you just put a


Declare Function DoYourThing Lib "plugin.dll" (Byval input as string) as string


in your (Declarations) part of a module.


I'm browsing the MSDN libraries for help, but it gets very complicated, so...


Can you explain it further to me? an example (if you have) would be great too!...


Regards,

Kevin.

[Chris Eastwood]

Hi Kevin


I think you're getting confused between Standard DLL's and ActiveX DLL's. A standard DLL (like the ones used in the WinAPI) must export functions - which is why you need the :


Public Declare FunctionName Lib "some.dll" (xxxx,xxxx)..... etc


An ActiveX DLL (for instance, the ones you create with VB) contain classes which you can create objects from, from another program, i.e.


Dim mObject As Object


Set mObject = CreateObject("MyProgram.ObjectToCreate")

mObject.CallMethodsEtc


Note, that an ActiveX EXE can contain these externally creatable classes too - they are called in the same way (well, there are some differences, but I shan't go into that now).


If you are writing your PlugIn DLL's in VB as ActiveX DLL's, I'd go along with what I originally wrote - you don't need to implement an Interface - it just makes it a lot more manageable.


1. You would install an ActiveX DLL 'Plugin' for your application

2. Your Installation would update a list somewhere of available plugins

3. Your Main Program can read the List and then Create an Instance of that plugin DLL.


For Instance :


Say your ActiveX DLL's all contain a Class called 'MyStartup', containing one method called 'DoYourThing' which takes a String as a parameter.


In Each Plugin DLL you would have the Class (MyStartUp) with the routine :


Public Sub DoYourThing(ByVal sStartupString As String)

'

' Individual processing for each Plugin DLL

'

..

..

End Sub


In your main program, you would access these plugins as such :


Private Sub StartPlugin(ByVal sPluginAppName As String) ' * See Below

Dim mPluginObject As Object

Dim sServerName As String



sServerName = sPluginAppName & ".MyStartUp"


Set mPluginObject = CreateObject(sServerName)


mPluginObject.DoYourThing "Some Value in a string!"


Set mPluginObject = Nothing

End Sub


Now this is a very simplified example with no error handling, but it assumes you pass in the application name to the StartPlugin procedure, which then does a CreateObject call on the class defined in your DLL. You'd need to surround this with some decent error handling.


***By the way - the 'application name' must be the same as that stated in your

'project->properties' window in VB (not the EXE name).****


I hope this gives you some more ideas - I'd _really_ recommend you lookup the following topics and research them for more ideas :


CreateObject

Implements

ActiveX / COM DLL's



Hope it gets you started


Regards


Chris Eastwood

CodeGuru - the website for developers

http://www.codeguru.com/vb

[Kevin]

Yes!

It totally worked as i had in mind.


Thank you very much!


Regards,

Kevin

[kevin]

Yes!

It totally worked as i had in mind.


Thank you very much!


Regards,

Kevin