Welcome to Omgili,
Omgili ( Oh My God I Love It ;) is a search engine for discussions. With Omgili you can find answers and solutions, debates, discussions, personal experiences, opinions and more... To learn more about Omgili click here.
This is a complete preview of the discussion as it was indexed by Omgili crawlers. Use this preview if the original discussion is unavailable.
Click here to view the original discussion.
[http://www.vbforums.com./showthread.php?t=538...]
Click here to search for discussions with Omgili discussions search engine.
 |
[RESOLVED] VB6 Module and Class Module - VBForums
Hey there, can someone explain it in simple words, Whats the difference between Module and Class Module?
When is better to use Module or when is better to use Class Module?
Thanks.
|
|
A Module (.bas) is just for code.
It is to group functions and variables that you want to be accessed from any other form or module.
A Class Module (.cls) is (sort of) an object.
You can put properties and methods in it.
For example I made a class module that contains code to play a CD.
It is setup as an object that I create an instance of and use it like this: CDPlayer.PlayCD.
Does this help?
|
|
A .bas module is a standard or static module.
It dates back to the days before VB, and all of it gets loaded statically when your program starts.
They aren't "just for code" because this is where you put data that must be global across the whole program.
Declaring data Public within a Form simply creates a read/write public property on the Form.
A .frm, .cls, or .ctl module is a dynamic module.
They're really all classes though they have different instantiation and container requirements and some of them have a predeclared instance by default (most Forms for example give you a "free" global instance with the same name as the Form's class).
The dynamic part refers to the data local to the class.
Creating an object of a class creates a unique copy of the data declared at class level scope.
Disposing of an object releases that data.
The point of using classes is that both the data to be operated upon and the operations to be performed upon that data can be encapsulated.
A program operating on an instance of a class doesn't need to know what goes on inside.
It becomes a sort of self-contained building block.
You can do the same thing with a bunch of UDTs and code in a static module, but you don't get the "black box" effect or the automatic memory management.
There is no simple answer to "Which is best, when?"
Generally everything should be a class unless (a.) it can't be, or (b.) as a class it would be all code and no class-scope data.
But that's a pretty sweeping generalization.
Classes are mostly about hiding the inner workings of compound items so you can focus on just using them.
|
|
|
Real simple?
You can compile a .DLL file from a class module....you can not from a .bas module.
Although this is true, a better discussion is dilettante's.
|
|
So what if you make a program with a Form and a (bas) Module, and in each one you have:
Code: Public Fred As String
???
The Object Browser shows one in <globals>
And one each in Form1 and Module1.
The answer is the <global>
One is the one in Module1.
The other one is really named Form1.Fred!
Potentially confusing at first, reusing the name in this way overloads the item in Form1's namespace...
Meaning code in Form1 doesn't get to the global Fred over in Module1 by using the name "Fred" at all.
Instead inside Form1 you'd need to say Project1.Fred or Module1.Fred to see the global Fred.
Take the Fred declaration out of Form1 though and the global Fred becomes visible as "Fred" again.
|
|
Wow, the man said simple words, hence my reply.
Nice explanation though, dilettante
|
|
Now the problem is....
How badly have I confused myself?
I'll be looking out for rabbit holes so I don't fall in.
Simple is best of course.
I'm just not good at simple.
|
|
|
|