Module Best Practices

[Paul]

I will be creating multiple VB.NET applications. I want all of the
applications to have some specific global user-defined public constants
and public variables (or objects). I currently have them in a module.
It works and I can easily reuse that module in each of my applications.
But then developers are able to change the module within a specific
application without changing it in the other applications. I want them
to all be the same.

What is the best way to handle this?

[Tom W]

Re: Module Best Practices

We too are creating multiple VB.NET applications. We have created a
single library of shared routines (in a dll) that includes all such
constants. The developers reference the dll which cannot be changed.
This does mean distributing a dll but it allows for creation of a nice
library of custom reusable objects.

Tom


Paul wrote:[color=blue]
> I will be creating multiple VB.NET applications. I want all of the
> applications to have some specific global user-defined public constants
> and public variables (or objects). I currently have them in a module.
> It works and I can easily reuse that module in each of my applications.
> But then developers are able to change the module within a specific
> application without changing it in the other applications. I want them
> to all be the same.
>
> What is the best way to handle this?
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Module Best Practices

Paul,
I would limit the use of Modules, instead rely on Classes with Shared
members.

Classes with Shared members provide better "encapsulation" , as you need to
qualify the constant/variable with the name of the class to use it, this way
you know exactly where the constant/variable is coming from...

To share Modules or Classes between projects, I would put the Module or
Class in a Class Library & reference the Class Library in each of the
projects.

http://msdn.microsoft.com/library/de...ryTemplate.asp

NOTE: With a class library each instance of each of your apps will have
their own copy of the variables in the class library. In other words the
variables will not be shared across applications.

Hope this helps
Jay

"Paul" <pwh777@hotmail .com> wrote in message
news:1123681071 .317508.262050@ z14g2000cwz.goo glegroups.com.. .
|I will be creating multiple VB.NET applications. I want all of the
| applications to have some specific global user-defined public constants
| and public variables (or objects). I currently have them in a module.
| It works and I can easily reuse that module in each of my applications.
| But then developers are able to change the module within a specific
| application without changing it in the other applications. I want them
| to all be the same.
|
| What is the best way to handle this?
|

[Paul]

Re: Module Best Practices

I agree that you want to limit (or not use) modules. However, I was
trying to have user-defined constants without having to instantiate the
class that the constants reside in. Is that possible?

Also, if you want all your applications to first run a Sub Main, you
must have a module that contains the Sub Main, right? Or is there a
way to do that without a module?

[Paul]

Re: Module Best Practices

I figured it out. I have a base class with the constants, etc. that I
need. Then every form I create will inherit that base class.

[Mitchell Vincent]

Re: Module Best Practices

Paul wrote:[color=blue]
> I figured it out. I have a base class with the constants, etc. that I
> need. Then every form I create will inherit that base class.
>[/color]

Show me? I'm the slow kid on the block (but would like to do something
like what you're doing!).

Thanks!

--
- Mitchell Vincent
- kBilling - Invoices Made Easy!
- http://www.k-billing.com

[Paul]

Re: Module Best Practices

Sure...now I have not tested it enough to know if this is going to work
as well as I want it to, but so far it is. Let me tell you what I am
doing first. That will help explain why I am doing all this.

I'm converting about 20 Microsoft Access applications to VB.NET.
Access has numerous constants (like acViewNormal), commands (like
DoCmd, SysCmd), enumerations, etc. that I will be converting to
something in VB.NET.

At first I created a public Sub in a module called DoCmdOpenForm (for
the DoCmd.OpenForm command in Access). And there were others. Also,
in this module I had created the Access constants. But I didn't want
to use a module.

So I created a class called AccessPublic. It inherits from
System.Windows. Forms.Form. Then within the class I declared all the
Public constants that I need. I also have a second class called
DoCmdObject. This second class contains the Subs that the Access DoCmd
executes like OpenForm. So in my AccessPublic class I also
instantiated a new DoCmd object with the following code:

Public DoCmd as New DoCmdObject

Now, all my application forms inherit from the AccessPublic class with
the following code:

Inherits AccessPublic

Now all my constants and the DoCmd code written in Access will work
just like they do in my .NET applications with very little conversion
needed. Here is an example:

Public Class Form1
Inherits AccessPublic

+ Windows Form Designer Generated Code

Private Sub Form1_Load(ByVa l sender As System.Object, ByVal e As
System.EventArg s) Handles MyBase.Load
Me.OpenArgs = "Add"
MessageBox.Show ("acViewNorm al: " & acViewNormal)
DoCmd.OpenForm( "FormName")
SysCmd()
End Sub
End Class

I do not get any syntax errors. Now I just need to put code into the
DoCmd (and other) subs. I created a second form (Form2) exactly like
Form1 because I wondered if the Public definition of the constants
would conflict. But they do not. So far it's working great!

Hope that helps.

[Jay B. Harlow [MVP - Outlook]]

Re: Module Best Practices

Paul,
Yes, as I mentioned in my first response, make the constants & variables
(the "members") Shared

BTW: Const are by their very nature Shared.

Public NotInheritable Class MyConstants

Public Const ProgId As String = "My Program Id"

Public Shared Readonly Name As String = "Jay"

Public Shared Sub DoWork()
End Sub

Private Sub New()
End Sub

End Class

You would then use MyConstants.Nam e, MyConstants.Pro gId, MyConstants.DoW ork
to get at the individual members. The Shared keyword allows you to use the
member without instanciating the class.

http://msdn.microsoft.com/library/de...akeyShared.asp

If I make all the members (subs, functions, fields, properties, events)
shared, then I also mark the class as NotInheritable which prevents other
from inheriting from this class, and add a Private Sub New which prevents
others from instantiating an object of the class. You can use Shared for
classes that are instantiated also, so Notinheritable or Private Sub New may
or may not be used in that case. For example a Parse or From* method, that
creates a new instance of class based on processing some data.


Note: you can use a variable to access a Shared member, however this can
lead to misleading code, such as Thread.Sleep.

Dim aThread As New Thread(...)

aThread.Sleep(1 00)

It appears in the above that aThread will sleep, while in actuality the
current thread will sleep, as Thread.Sleep is shared method that acts on
Thread.CurrentT hread.

Hope this helps
Jay



"Paul" <pwh777@hotmail .com> wrote in message
news:1123690138 .847558.129970@ g14g2000cwa.goo glegroups.com.. .
|I agree that you want to limit (or not use) modules. However, I was
| trying to have user-defined constants without having to instantiate the
| class that the constants reside in. Is that possible?
|
| Also, if you want all your applications to first run a Sub Main, you
| must have a module that contains the Sub Main, right? Or is there a
| way to do that without a module?
|