how to create object of DLL in Module, not Form?
I created 2 classes in my DLL, 1st is only the interface of all functions, 2nd is the implementation of them. Then I referenced it to an other project (with Form & Module). When I create the object of my dll in the Form, I wrote:-
Dim dll as Project.Interface
'...
set dll as Project.Implementation
But, when I tried to create the dll object in Module, it doesn't work where I wrote:-
Dim dll as new Project.Interface
Please help!!!
Ivy
[510 byte] By [
ilin] at [2007-11-15 16:17:25]
# 1 Re: how to create object of DLL in Module, not Form?
You cannot use the new parameter when using an interface. This is because the interface does not know and does not care what objects implement it, so it can't forward the call to an object. By definition, an interface does not contain any implementation, so it won't be able to handle the call itself. Finally, the interface should be PublicNonCreatable, which explicitly prevents it from being created as an object.
This forces us to do it in 2 steps.
One thing I want to note is that it is better to add refference to the project only for the interface, not for the object. This is because if the object changes, you are forced to remove the refference to both the interface and the object, and add them again. If this happens to a compiled program, your program won't even run. You can do this by seperating the interface and the implementation into two seperate dlls, and use CreateObject in stead of Set As New. This way, you won't break your existing programs (cause several programs might be using the object) when the implementation (object, not interface) changes.
Tom Cannaerts
slisse@planetinternet.be
Programming today is a race between software engineers striving to build bigger and better idot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning -- Rich Cook
Cakkie at 2007-11-10 0:59:04 >
# 2 Re: how to create object of DLL in Module, not Form?
Thanks Cakkie.
I added reference of the dll I created to the project, which is the user-interface. If I'd to call functions form the dll in a Module of the project, I cannot write "Set dll = New InterfaceClass", should I use "CreateObject" in every functions inside the Module? Will it create lot of copies of the dll? I can now solve the problem if I delcare "Public dll As InterfaceClass"; then I call New InterfaceClass in the Form of my project. Since dll is now a global object, the implementation of the dll can now work.
Can you explain more about " by seperating the interface and the implementation into two seperate dlls"?
Ivy
ilin at 2007-11-10 0:59:59 >
# 3 Re: how to create object of DLL in Module, not Form?
CreateObject actually does the same as New, with the difference that CreateObject is a late-bound and New is Early-bound method. This is a topic we can talk for hours about, but we are not going to. But eventually, if you use New or CreateObject, the result will be the same object. This also means you can still use public dll as InterFaceClass.
Now, about the seperating part. First note that this is only the case if using CreateObject, this does not work with New.
If you like it or not, you must add a refference to your interface class. If the objectclass (the one that implements the interface) is in the same dll, a refference is added automatically. In this case, if you change the code in the objectclass, you would have to remove the refferences to the dll (including those of the interface), and add them again, recompile your exe and redistribute the dll and exe to all places your program is installed. If that dll is used in other programs as well, you will have to recompile those programs and redistribute them. You can imagine that this is very painfull and time consuming.
If however, you create a dll that contains only the interface, and a dll which contains only the implementation, you have 2 dlls (duh). To your program you add a refference to the interface (not to the implementation). Then, when the implementation changes, you would only need to recompile the dll with implementation, and redistribute it. no need to recompile your program, no need to recompile any other programs, just copy the dll to the location of the other dll and you are ready to go. In 99% of the time, you don't even need to reregister the dll, if so, just use regsvr32.
There are only 3 things you need to keep in mind when creating the interface and implementation.
First, just create a new dll, write the interface, and compile it to a dll. Then right click the project in the project explorer and select properties. Go to the component tab and select binary compatibility. Recompile the dll.
Secondly, for the implementation you do the same, but you set the compatibility to Project compatibility.
Finally, if you only have interfaces in your dll (which you should have), and the interfaces are set to PublicNonCreatable, your dll won't compile. Just add a class module to the project and set it to Multiuse, now your dll should compile.
This is all it takes to save a lot of time (believe me, I've been there)
Tom Cannaerts
slisse@planetinternet.be
Programming today is a race between software engineers striving to build bigger and better idot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning -- Rich Cook
Cakkie at 2007-11-10 1:01:00 >
# 4 Re: how to create object of DLL in Module, not Form?
I'm now a lot clear of what you mean by 2 dlls.
If I'm going to do a type library .tlb of the dll, will it act the same as the interface dll? So does it mean I don't have to do the interface dll? Which is a better way?
Ivy
ilin at 2007-11-10 1:02:06 >
# 5 Re: how to create object of DLL in Module, not Form?
Too bad I am already out of votes!
Special thanks to Lothar "the Great" Haensler, Tom Archer, Chris Eastwood,
Bruno Paris and all the other wonderful people who made and make dev-archive
a great place.
Come back soon, you Gurus.
# 6 Re: how to create object of DLL in Module, not Form?
Again, this is something I could talk hourse about, but not planning to. Both things have there pros and cons.
Not using an interface means not having to worry about breaking compatibility. If you change your component, you should not need to worry to much about programs not working, as long if you don't remove any methods/properties. Recompilation of the dll and reregistering it should suffice. This method in is good enough in most cases, but in some cases you want, or must make use of interfaces.
One of the mayor advantages of interface programming is that when you work in team, you can start programming a program as soon as the interfaces of the objects are ready. You don't need to wait until the component itself is ready, cause if it supports an interface, you canbe sure that the object you call will have the method, with all the parameters and return types as defined in the interface. Say you have two people, one develops the interface, once that is done, he can start programming the implementation, while the other can start writing a program that uses the components.
Another great thing about interfaces is Polymorphism. For those who never heard of it, it comes down to this: you have a refference to an object without knowing what object you are holding. Ok, I'll explain:
We have 1 interfaces, and 2 objects:
' interface iDog
public Function Bark() as string
End Function
' object cDoc
Implements iDog
private Function iDog_Bark() as string
iDog()Bark = "Woef"
End Function
' object cWonderDoc
Implements iDog
private Function iDog_Bark() as string
iDog()Bark = "WoefWoef"
End Function
So I like dogs ;)
Now let's say I have a program that has a form with two optionbuttons on it and a command button. The two options are "Snoopy" and "Lassie", and the command button reads "Bark".
private Sub Command1_Click
Dim myDog as iDog
If Option1.Value then
' Snoopy
set myDog = CreateObject("cDog")
else
' Lassie
set myDog = CreateObject("cWonderDog")
End If
msgbox myDog.Bark()
End Sub
At the time we program this, we cannot know what object we are holding at the time we call the Bark method. What we can sure of is that myDog is of the type iDog, and that iDog has a method called Bark. Since both cDog and cWonderDog implement iDog, they must have this method.
In this case, the difference between them is that the one returns "woef", and the other "woefwoef".
In reality, you can use these things like say for an employee database. All people are of the interface iEmployee, but when you call the GiveRaise method, a simple employee will only get 2% more, where a staff member gets 10% more.
Tom Cannaerts
slisse@planetinternet.be
Programming today is a race between software engineers striving to build bigger and better idot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning -- Rich Cook
Cakkie at 2007-11-10 1:04:09 >
# 7 Re: how to create object of DLL in Module, not Form?
thank you!! for pointing out Tom's entries, and thank you Tom, as they have been very helpful in furthering my understanding! Having recently encountered an ms bug in the vbe which requires late binding, it has been a less than pleasant learning process. i have many more questions and less time than ever...
thank you!!
e
EAK at 2007-11-10 1:05:05 >
# 8 Re: how to create object of DLL in Module, not Form?
Tom, you say "99% of the time you don't even need to register the dll...". Can you tell me about the 1% and how I may anticipate the need to register the dll?
thank you!
Elizabeth
EAK at 2007-11-10 1:06:10 >
# 9 Re: how to create object of DLL in Module, not Form?
In some cases you need to reregister a dll.
When? Well, if your object has got new PUBLIC methods or properties. Note that a public veriable will be treated as a property. If you add private methods to your object, or you just change the code of an existing public method (just the code, not the signature, that is, the number, order or datatype of the parameters, or the return type in case of a function), you won't need to reregister. Since we are talking interfaces here, that would mean that your interface should change, and I can say one thing, DON'T. Never change an interface, rather, create a second interface that extends everything of the first. This way, old programs will still be able to work with you object, cause it supports the interface, and new programs can use the new interface. One of the projects i'm currently working on has about 60 components (and counting), which eventually make use of the same component to access the database. If I were to change the interface of that component, it would result in me having to renew the refference to the component in all the other components, and recompile them, and reinstall them on every computer the program is installed on. That could cost me a couple of days to do, so don't touch your interface once it is finished, EVER.
To put the above in in human language, if the looks of it (typelibrary) doesn't change, you don't need to reregister.
To reregister the dll, you just need to run regsvr32 (located in the windows\system or system32 directory from a dosprompt (or using the shell method from vb). This program will insert/update all the nessecairy registry keys for you.
Tom Cannaerts
slisse@planetinternet.be
Programming today is a race between software engineers striving to build bigger and better idot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning -- Rich Cook
Cakkie at 2007-11-10 1:07:12 >
