|
-
Feb 27th, 2000, 08:26 PM
#1
Thread Starter
Lively Member
If I create a function like this:
Code:
Public Function DoStuff()
'Do Some Stuff Here!
End Function
In a Class Module, and then compile it to a DLL, and then if I want to call this dll later on Runtime from my application, and use that function, how do I Do ?
If I have called the DLL, could I just use the command "DoStuff" ?
-
Feb 27th, 2000, 08:40 PM
#2
Hyperactive Member
Yeh! thats about it.
You will need to reference it in Project- references,
and if you change workstations you will need to bring it with you and register it with REGSVR32.
-
Feb 28th, 2000, 02:07 AM
#3
Thread Starter
Lively Member
Thanks, but do I really really have to add it in References ?
Isn't there any other way to do it ?
I want to make addon Dll's, and since the user can't change the source all the time, I want to be able to use a dll that's not in References..
-
Feb 28th, 2000, 02:30 AM
#4
Hyperactive Member
I don't really get you Zleepy, if you compile it and leave it as a seperate project, you will have to reference it. Otherwise you would have to physically include it in your project. Maybe what you want here is to set up a template that the user can select and just add in? Thats straight forward enough , just create it and save it as a template into the VB6 templates folder. But it really would be easier to compile and then just register it on the other users machine.
Have I answered your question? or have I just made up one of my own and answered that instead?
-
Feb 28th, 2000, 02:38 AM
#5
Thread Starter
Lively Member
Hmm, yeah you're right, I was just beingg stupid, sorry and thanks for the help.
-
Feb 28th, 2000, 08:06 AM
#6
Hyperactive Member
I hate having to use Project>References, because version control is a nightmare when sharing code on a project.
is there any way to make a "c style" DLL in VB?..
ie. Declare Function Lib "MyDll" MyFunction()
?? 
buzzwords are the language of fools
-
Feb 28th, 2000, 02:12 PM
#7
DLL's
Why is no one using CreateObject? Aside from turning binary compatibility on, this is a very stress relieving way of testing your dll's. That way you just call it by name and forget about the references section of the projects menu. However, it does require you to remember everything about your object(i.e. late binding) If you've designed your COM objects well enough and once you're pretty sure that your interface will never change(or at least not until the next release), set the binary compatibility option on. So long as you don't add any public interfaces you can recompile new code without generating a new GUID for your component.
I believe the C-style dll's require pointers and are not 'normally' possible in VB although I bet someone's come up with a hack for that one. I wouldn't think it would be worth the effort, may as well just do it in C++, but as I'm learning, VB hides A TON of information from you when constructing COM Servers and Clients(dlls)...
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|