How to use a Module.

Hi All,

I try to use a module for the first time and this is the way I used it.
I've got a module and I've added to my application with ' add module ' then I've tryed to show the result of this module on my form like this;

VB Code:

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Module1.Main()
    End Sub

But it didn't worked, however in the Output debugger I can see what the module does.
What do I have to do next that the result of this module show up on my Form.

Or did I do something totally wrong how to use a module.
If so, can someone tell me how to use a module in an application.

Thanks in advance,

sparrow1

You seem to be treating a module like a class!
If you want your module to return something, why dont you just create a class!

...maybe i am wrong and i stand to be corrected but i use modules to just store public related functions that i can just easily access from anywhere.

Modules don't have results. A module is a container for methods, properties and other members. You access those members just like you do any other properties or methods. They behave just like Shared members of a class in that you don't have to create an object on which to call them. The difference with a module is that you don't have to specify the module name either, although you can.

My question is: why are you using a module at all if you don't know how to use one? There is no necessity to use modules in VB. In fact some people consider it a crime to do so at all. The more .NET way would be a class with all Shared members, like the IO.File or IO.Directory classes. If you aren't using a module to solve a specific problem then why bother at all?

Quote:

---

Originally Posted by jmcilhinney

Modules don't have results. A module is a container for methods, properties and other members. You access those members just like you do any other properties or methods. They behave just like Shared members of a class in that you don't have to create an object on which to call them. The difference with a module is that you don't have to specify the module name either, although you can.

My question is: why are you using a module at all if you don't know how to use one? There is no necessity to use modules in VB. In fact some people consider it a crime to do so at all. The more .NET way would be a class with all Shared members, like the IO.File or IO.Directory classes. If you aren't using a module to solve a specific problem then why bother at all?

---

Hi,

I was just curious how to use one and what the result would be.
Anyway thanks for your replies, I've learned something more about .net.

Thanks,

sparrow1

Quote:

---

Originally Posted by jmcilhinney

There is no necessity to use modules in VB. In fact some people consider it a crime to do so at all. The more .NET way would be a class with all Shared members, like the IO.File or IO.Directory classes.

---

Of course they are. Those are usefull to place public variables, procedures and constantas. Altough a class can have the same functionality, you don't have to initialize modules to use those publics.

Quote:

---

Originally Posted by michaelrawi

Of course they are. Those are usefull to place public variables, procedures and constantas. Altough a class can have the same functionality, you don't have to initialize modules to use those publics.

---

Hi,

Can you explain me a little more about it.
For example I've got a public variable in a module, how can I use it so that it will executed on the form like a class.

Wkr,

sparrow1

Quote:

---

Originally Posted by michaelrawi

Of course they are. Those are usefull to place public variables, procedures and constantas. Altough a class can have the same functionality, you don't have to initialize modules to use those publics.

---

You've completely missed the point. I didn't say that you can't use modules, just that it's not necessary. Also, a class with Shared members doesn't require an instance to be created to have those members used either. The File and Directory classes are prime examples. You should NEVER create an instance of either because all the useful members are Shared. In fact, modules have only been kept around for backward-compatibility. They don't actually exist at all. When you compile your VB code a module is implemented as a class with all Shared members and no public constructor. Modules are only a facade that appears to be the same as VB6 modules but is actually a .NET class underneath. The only thing that a module offers over a class is that you don't have to qualify a member of a module with the module name, while with a class you do. Many would not consider that a positive thing anyway.

Supposed you have a module

VB Code:

Module Main
#Region "Public Variables"
Public Bla as string
#End Region
 
#Region "Public Constanta"
Public Const Const1 as string="bla"
#End Region
End Module

There's 2 way you can call those 2 variable
Either:

VB Code:

messagebox.show(const1)

Or use this

VB Code:

messagebox.show(Main.const1)

All of them works, except, in 2nd way, you know that const1 is in Main module (usefull method if you work with more than one module).

Hope it helps

Quote:

---

Originally Posted by jmcilhinney

You've completely missed the point. I didn't say that you can't use modules, just that it's not necessary. Also, a class with Shared members doesn't require an instance to be created to have those members used either. The File and Directory classes are prime examples. You should NEVER create an instance of either because all the useful members are Shared. In fact, modules have only been kept around for backward-compatibility. They don't actually exist at all. When you compile your VB code a module is implemented as a class with all Shared members and no public constructor. Modules are only a facade that appears to be the same as VB6 modules but is actually a .NET class underneath. The only thing that a module offers over a class is that you don't have to qualify a member of a module with the module name, while with a class you do. Many would not consider that a positive thing anyway.

---

Ah, that's right. Forgot about shared members. But IMO, shared members isn't part of an OOP since it can be used anywhere without initialize. That's why, I'd prefer use modules for public variables rather that place it on a class.

Quote:

---

Originally Posted by michaelrawi

Ah, that's right. Forgot about shared members. But IMO, shared members isn't part of an OOP since it can be used anywhere without initialize. That's why, I'd prefer use modules for public variables rather that place it on a class.

---

I'm not trying to be rude but just stating a fact when I say that I find that ridiculous. To say that you won't use a Shared member of a class because it's not OO and then use a module is like saying you won't ride a donkey because it's not a horse and then riding a sheep instead.

First of all, modules are completely unrelated to objects as they are used in VB. VB is the only OO language to have modules because, as I said, they wanted to be compatible with old VB. No other OO language uses them because they don't serve a purpose that isn't already served by Shared members of a class.

Secondly, as I said, modules are implementedas classes with Shared members when they're compiled anyway, so you are using Shared members of classes anyway.