I have a really huge BANK of functions in my executable ( which they are all in modules )
will my application load faster if i put all my functions in a single dll ?? :confused:
tnkz
Printable View
I have a really huge BANK of functions in my executable ( which they are all in modules )
will my application load faster if i put all my functions in a single dll ?? :confused:
tnkz
Does your executable load really slowly? How big is your executable?
Most modern machines can load an executable in less than a second, even if it is relatively large. An application that starts slowly usually starts slowly because it has to do a lot of initialization stuff, so the speed of your app does not really depend on the size (unless you are using a machine with very low specs or your app is really really very large.
Shrog
thanks for replying shrog...
well i guess you're right..i was exedurading when i said i have a BANK of function...it is exactly 40K ( which is also quite a lot )
anyways , what you're saying is that the size of the exe is not relative to the question why my app loads fast or slow....
ok..but i think i still have some problems in my program which involves the loading time thing...
yet my problem is mainly about configurations my app needs to load from the registry at Form_Load().
Still...I Dont understand one main thing :
If like you said , having a dll doesn't make the app to load faster or slower than WHAT IS THE PURPOSE OF DLLS???
Another question :
How do i make\create dlls in visual basic??
is it like a simple module which is being compiled...??
:confused::confused::confused::confused::confused:
tnk
The purpose of a DLL is much more important than mere size. Today's computers seem to have an endless supply of space. On my home computer, I have a quarter of a Gig memory and a swapfile that is 1 Gig in size, and my friends consider my computer to be outdated. I don't think that it makes a difference whether my app is 0.4Mb or 0.9Mb in size.
DLL's are all about sharing, modularization and upgradebility (did I spell those correctly?).
Every time you write an application, there are certain things that you have to code every time. Like file handling for example - letting the user save or load data, checking if the file is the correct format, checking if the file exists, asking the user whether it's OK to overwrite a file, checking for enough disk space, etc. After a while you get tired of coding the same old things for every application.
So this is where you can create a DLL. The DLL contains all the functionality that you need. You simply reference it in all your applications and call the methods as you need them.
Now let's say for example you have a DLL like that, and you have 5 or 6 different applications using this DLL. Then one day you find there is a better way of opening a file. All you do is change the coding in the DLL and all your applications will automatically be updated. You can email this one DLL file to all your users, and their applications will all be updated.
Someone who writes a lot of card games will use a DLL that will have Card objects, Suite objects, Deck objects, with Deal and Shuffle methods, etc.
A DLL is like a control, but without the visual part of it. Every time you use a command button, you do not have to write the coding to make it work, it is all built into the control. All you have to do is set the properties, call the methods and respond to the events. The same with DLL's.
I can carry on and on about this. I think I better stop now.
In answer to your other questions: Yes, you can very easily create DLL's with Visual Basic. You have to keep in mind that they are ActiveX DLL's, and not API DLL's.
You use an API DLL by "Declaring" the functions you want to use, and then calling those functions like they are VB commands.
You use an ActiveX DLL by "Referencing" the DLL in the project references, and then creating instances of it's classes (objects). You can then call the methods of the objects.
When you create a new project in VB, you will be given the option to choose the type of application. Select "ActiveX DLL" instead of "Standard Exe".
Hope this helps
Shrog
here is another idea, just like the Active X DLL, you could use Active X EXEs in the same way. The only important differences between the two is that DLLs run in the calling programs aloted memory, while an EXE is aloted memory of it's own. This means if the function your calling crashes, it won't drag your calling program down with it.