Global varible

[shankar_it]

I have declared a srting in Form 1

 

Dim AUDTYPE As String

 

i want to use this varible in any form

 

Is there a way to declare this varible as global.I am new to VB.net programing.Can any one help in this?.

[shankar_it]

I am using this in VB.net windows form

 

 

I have declared a srting in Form 1

 

Dim AUDTYPE As String

 

i want to use this varible in any form

 

Is there a way to declare this varible as global.I am new to VB.net programing.Can any one help in this?.

[jmcilhinney]

Create a module (you do this in the Solution Explorer just like for a class) and declare your variable there instead of in your form. Also, only use "Dim" in procedures and functions. At the class or module level you should use "Private", "Public", etc.

[shankar_it]

I did create a module and just typed in

 

Dim AUDID as String

 

but form1 does not recognise AUDID

 

Do i have to add this module in each and every form,If so can you please tell me the command to do it.

 

 

Create a module (you do this in the Solution Explorer just like for a class) and declare your variable there instead of in your form. Also' date=' only use "Dim" in procedures and functions. At the class or module level you should use "Private", "Public", etc.[/quote']

[Machaira]

In your declaration of the variable change Dim to Public and you should be good. By default Dim means the scope is local, which in this case is the module, not any forms in the project.

[shankar_it]

Thank you for your help

 

In your declaration of the variable change Dim to Public and you should be good. By default Dim means the scope is local' date=' which in this case is the module, not any forms in the project.[/quote']

[jmcilhinney]

Quite correctly, Machaira has pointed out that using Dim to declare a class- or module-level variable has the effect of making it private. Good programming practice dictates that you ONLY use Dim to declare LOCAL variables, i.e. within a procedure or function. You should always use Public, Private, Friend, etc. when declaring class- or module-level variables.

[Joe Mamma]

what you want is a Global Class with a hidden constructor that has a static Property that returns a singleton instance of the Global class and the global variables are properties of the class, something like this -

 

Public Class Globals
Private Shared mInstance As Globals
Private mString As String
Private mInteger As Integer
Private mObject As Object

' HIDE THE CONSTRUCTOR SO ONLY ACCESSIBLE VIA INSTANCE
Private Sub New()
End Sub

Public Property AppString() As String
	Get
		Return mString
	End Get
	Set(ByVal Value As String)
		mString = Value
	End Set
End Property

Public Property AppInteger() As Integer
	Get
		Return mInteger
	End Get
	Set(ByVal Value As Integer)
		mInteger = Value
	End Set
End Property

Public Property AppObject() As Object
	Get
		Return mInteger
	End Get
	Set(ByVal Value As Object)
		mObject = Value
	End Set
End Property

Shared ReadOnly Property Instance() As Globals
	Get
		If mInstance Is Nothing Then mInstance = New Globals
		Return mInstance
	End Get
End Property
End Class

Usage, from anywhere in the app, is like this:

TextBox1.Text = Globals.Instance.AppString
Globals.Instance.AppString = "Foo Bar"
dim i as integer = Globals.Instance.AppInteger
Globals.Instance.AppInteger = 100
Globals.Instance.AppObject = Me

[jmcilhinney]

what you want is a Global Class with a hidden constructor that has a static Property that returns a singleton instance of the Global class and the global variables are properties of the class, something like this -

 

Public Class Globals
Private Shared mInstance As Globals
Private mString As String
Private mInteger As Integer
Private mObject As Object

' HIDE THE CONSTRUCTOR SO ONLY ACCESSIBLE VIA INSTANCE
Private Sub New()
End Sub

Public Property AppString() As String
	Get
		Return mString
	End Get
	Set(ByVal Value As String)
		mString = Value
	End Set
End Property

Public Property AppInteger() As Integer
	Get
		Return mInteger
	End Get
	Set(ByVal Value As Integer)
		mInteger = Value
	End Set
End Property

Public Property AppObject() As Object
	Get
		Return mInteger
	End Get
	Set(ByVal Value As Object)
		mObject = Value
	End Set
End Property

Shared ReadOnly Property Instance() As Globals
	Get
		If mInstance Is Nothing Then mInstance = New Globals
		Return mInstance
	End Get
End Property
End Class

Usage, from anywhere in the app, is like this:

TextBox1.Text = Globals.Instance.AppString
Globals.Instance.AppString = "Foo Bar"
dim i as integer = Globals.Instance.AppInteger
Globals.Instance.AppInteger = 100
Globals.Instance.AppObject = Me

If we were using C# then I would agree with you, but given that we are using VB.NET, why complicate matters when a module provides essentially the same functionality without the complexity?

 

Edit:

You may be thinking "what complexity", but believe me, many people don't fully understand what static/shared means, and private constructors will defintiely confuse some people.

[Joe Mamma]

You may be thinking "what complexity", but believe me, many people don't fully understand what static/shared means, and private constructors will defintiely confuse some people.

As I said along time ago. . . VB6 made alot of poor programmers.

 

 

First of all. . . stop thinking VB and think .NET. The question was from someone who understands, atleast basically, the VB6 way of doing things, what he wants is the .NET way of doing things.

 

This approach actually simplifies the situation and is a truly modular solution. Also, what I would do is put the Globals class in its own assembly. That way the application wide data is in a cohesive package decoupled from the user interface.

 

And if people dont know what static/shared methods/properties and hidden constructors are, I highly recommended that, before they do anything else, understand them.

 

That is, if they don't want their programs hijacked :eek: (I will let you think about that for a while. ;) )

[michael_hk]

And if people dont know what static/shared methods/properties and hidden constructors are, I highly recommended that, before they do anything else, understand them.

Agree.

 

But in reality, many programmers just won't care what all this stuff is about as long as their programmes work. Eg, they don't think making everything public is a problem. The crux is your and their standard are different.

[DiverDan]

I agree with Joe Mamma. With Option Strict On and the proper .Net code applications and interfaces, not only do the programs run faster, but once you've used true OOP programming, debugging is even easier...something very critical with large, complicated projects. This forum used to only support these policies...I hope that hasn't changed.

[Machaira]

As I said along time ago. . . VB6 made alot of poor programmers.

I agree, but this isn't necessarily the case here.

This approach actually simplifies the situation and is a truly modular solution. Also, what I would do is put the Globals class in its own assembly. That way the application wide data is in a cohesive package decoupled from the user interface.

So in the end what's the difference between using a module and what you've done? What's the benefit for doing it your way? Using a module still provides for a modular solution without all the fuss of using a class.

I agree with Joe Mamma. With Option Strict On and the proper .Net code applications and interfaces, not only do the programs run faster, but once you've used true OOP programming, debugging is even easier...something very critical with large, complicated projects. This forum used to only support these policies...I hope that hasn't changed.

"proper .NET code"? So using modules isn't "proper .NET"? MS must think there's a reason for them. They're still a part of VB.NET 2005. Using a module doesn't increase the difficulty of debugging, doesn't slow it down, doesn't break OOP methodology, and, above all, doesn't make it more complex than it needs to be.

[Joe Mamma]

So in the end what's the difference between using a module and what you've done? What's the benefit for doing it your way? Using a module still provides for a modular solution without all the fuss of using a class.

Call it a preemptive strike. The coding might seem more complex but I assure you, it isn't. Simplicity in coding often leads to complexity in process.

 

Classes are extensible while modules are not.

The accessor methods on the class provide the ability to perform checking and perhaps event raising.

 

"proper .NET code"? So using modules isn't "proper .NET"? MS must think there's a reason for them. They're still a part of VB.NET 2005. Using a module doesn't increase the difficulty of debugging, doesn't slow it down, doesn't break OOP methodology, and, above all, doesn't make it more complex than it needs to be.

Modules by definition are not OOP, they are structured. The complexity isn't in the code but the architecture. Down the line you are bound to say things along the lines of

 

'Man I wish I could add a new global variable, but I dont want to manage two different modules - I want them all within the same structure!'

or

'Man, I wish this service could automatically intercept when any service attempts to change a global variable!'

or

'Man, I wish that service, could automatically be made aware of when any service has changed this global variable!'

 

Well take a look at this approach that takes care of all three:

 

Public Delegate Sub AppStringChangingHandler(ByVal sender As Object, ByVal e As AppStringChangingArgs)
Public Delegate Sub AppIntegerChangingHandler(ByVal sender As Object, ByVal e As AppIntegerChangingArgs)
Public Delegate Sub AppObjectChangingHandler(ByVal sender As Object, ByVal e As AppObjectChangingArgs)

Public Class AppStringChangingArgs
Inherits System.ComponentModel.CancelEventArgs
Public NewString As String
Public Sub New(ByVal value As String)
	NewString = value
End Sub
End Class

Public Class AppIntegerChangingArgs
Inherits System.ComponentModel.CancelEventArgs
Public NewInteger As Integer
Public Sub New(ByVal value As Integer)
	NewInteger = value
End Sub
End Class

Public Class AppObjectChangingArgs
Inherits System.ComponentModel.CancelEventArgs
Public NewObject As Object
Public Sub New(ByVal value As Object)
	NewObject = value
End Sub
End Class

Public Class Globals
Protected Shared WithEvents mInstance As Globals
Private mString As String
Public Event AppStringChanging As AppStringChangingHandler
Public Event AppStringChanged As EventHandler

Protected Sub New()
End Sub

Public Property AppString() As String
	Get
		Return mString
	End Get
	Set(ByVal Value As String)
		Dim args As New AppStringChangingArgs(Value)
		RaiseEvent AppStringChanging(Me, args)
		If args.Cancel Then Return
		mString = Value
		RaiseEvent AppStringChanged(Me, EventArgs.Empty)
	End Set
End Property

Public Shared ReadOnly Property Instance() As Globals
	Get
		If mInstance Is Nothing Then mInstance = New Globals
		Return mInstance
	End Get
End Property
End Class

Public Class ExtendedGlobals
Inherits Globals
Private mInteger As Integer
Private mObject As Object
Public Event AppIntegerChanging As AppIntegerChangingHandler
Public Event AppObjectChanging As AppObjectChangingHandler
Public Event AppIntegerChanged As EventHandler
Public Event AppObjectChanged As EventHandler

Protected Sub New()
	MyBase.New()
End Sub

Public Property AppInteger() As Integer
	Get
		Return mInteger
	End Get
	Set(ByVal Value As Integer)
		Dim args As New AppIntegerChangingArgs(Value)
		RaiseEvent AppIntegerChanging(Me, args)
		If args.Cancel Then Return
		mInteger = Value
		RaiseEvent AppIntegerChanged(Me, EventArgs.Empty)
	End Set
End Property

Public Property AppObject() As Object
	Get
		Return mInteger
	End Get
	Set(ByVal Value As Object)
		Dim args As New AppObjectChangingArgs(Value)
		RaiseEvent AppObjectChanging(Me, args)
		If args.Cancel Then Return
		mObject = Value
		RaiseEvent AppObjectChanged(Me, EventArgs.Empty)
	End Set
End Property

Public Shared Shadows ReadOnly Property Instance() As ExtendedGlobals
	Get
		If mInstance Is Nothing Then mInstance = New ExtendedGlobals
		Return mInstance
	End Get
End Property
End Class

 

Granted, it Probably looks complex, but that is inherent to the inferiority of VB.NET syntax. . . give me a moment and I will do it in c# and you will see what I am talking about. . .

Edited July 8, 2005 by Joe Mamma

[Joe Mamma]

and in C#

[CS] public delegate void AppStringChangingHandler(object sender, AppStringChangingArgs e);

public delegate void AppIntegerChangingHandler(object sender, AppIntegerChangingArgs e);

public delegate void AppObjectChangingHandler(object sender, AppObjectChangingArgs e);

public class AppStringChangingArgs : System.ComponentModel.CancelEventArgs

{

public string NewString;

public AppStringChangingArgs (string value)

{

NewString = value;

}

}

public class AppIntegerChangingArgs : System.ComponentModel.CancelEventArgs

{

public int NewInteger;

public AppIntegerChangingArgs(int value)

{

NewInteger = value;

}

}

public class AppObjectChangingArgs : System.ComponentModel.CancelEventArgs

{

public object NewObject;

public AppObjectChangingArgs(object value)

{

NewObject = value;

}

}

public class Globals

{

protected static Globals mInstance;

private string mString;

public event AppStringChangingHandler AppStringChanging;

public event EventHandler AppStringChanged;

protected Globals(){}

 

public string AppString

{

get{ return mString;}

set

{

if (AppStringChanging != null)

{

AppStringChangingArgs args = new AppStringChangingArgs(value);

AppStringChanging(this, args);

if (args.Cancel) return ;

}

mString = value;

if (AppStringChanged!=null)

AppStringChanged(this, EventArgs.Empty);

}

}

public static Globals Instance

{

get

{

if (mInstance ==null) mInstance =new Globals();

return mInstance;

}

}

}

public class ExtendedGlobals : Globals

{

private int mInteger;

private object mObject;

public event AppIntegerChangingHandler AppIntegerChanging;

public event AppObjectChangingHandler AppObjectChanging;

public event EventHandler AppIntegerChanged;

public event EventHandler AppObjectChanged;

protected ExtendedGlobals(){}

public int AppInteger

{

get {return this.mInteger;}

set

{

if (AppIntegerChanging != null)

{

AppIntegerChangingArgs args = new AppIntegerChangingArgs(value);

AppIntegerChanging(this, args);

if (args.Cancel) return ;

}

mInteger = value;

if (AppIntegerChanged!=null)

AppIntegerChanged(this, EventArgs.Empty);

}

}

public object AppObject

{

get {return this.mObject;}

set

{

if (AppObjectChanging != null)

{

AppObjectChangingArgs args = new AppObjectChangingArgs(value);

AppObjectChanging(this, args);

if (args.Cancel) return ;

}

mObject = value;

if (AppObjectChanged!=null)

AppObjectChanged(this, EventArgs.Empty);

}

}

 

public new static ExtendedGlobals Instance

{

get

{

if (mInstance ==null) mInstance =new ExtendedGlobals();

return mInstance as ExtendedGlobals;

}

}

}[/CS]

[DiverDan]

Adding to Joe Mamma's excellent examples is what happens if you have two modules that share the same variable? Your program won't know which to use because modules are not defined in their variable use while classes are.

[jmcilhinney]

For Joe Mamma

Visual Basic .NET modules are actually special classes even though they are not created with the Class keyword. The compiler generates a NotInheritable (sealed) class that contains only Shared methods. A module can contain a Shared constructor but no instance constructors. The compiler does not generate a default constructor nor can you declare a private constructor. Therefore you cannot create an object from a module.

 

A module is implicitly imported into every source file in a project so the methods and properties of the module can be accessed without being fully qualified. This provides the same functionality as global methods and variables available in prior versions of Visual Basic.

 

Modules give you a quick and convenient mechanism for exposing shared functions and variables. When programming against the .NET Framework, many other languages require you to explicitly create a NotInheritable class, explicitly make all methods Shared, and create a private constructor (most compilers create a default constructor if you do not at least provide a private one).

 

Recommendation: Since modules fit completely within the object-oriented conventions of the .NET Framework, Visual Basic .NET programmers should not hesitate to use them when appropriate.

This is taken from this article on MSDN, which I personally found quite informative and eye-opening. It dispelled some assumptions that I'd made about VB.NET. While many of the things you say about classes over modules is correct, the use of modules should not, in any way, be considered improper, assuming the situation is suitable.

[Joe Mamma]

Recommendation: Since modules fit completely within the object-oriented conventions of the .NET Framework, Visual Basic .NET programmers should not hesitate to use them when appropriate.

A Posteriori. . .

 

Because it can lull programmers into using archaic VB conventions, object-oriented programmers should hesitate to use VB.NET. :p

[jmcilhinney]

A Posteriori. . .

 

Because it can lull programmers into using archaic VB conventions, object-oriented programmers should hesitate to use VB.NET. :p

So we shouldn't use modules because they are not OO, but if they are OO we shouldn't use them because they can lull us into using some unspecified archaic conventions, but if we understand them and their limitations properly and are not lulled then we shouldn't use them because they have the same name as something in VB6 and VB6 is bad. Now I get it.

[Joe Mamma]

no I am saying. . .

 

Because VB.NET can lull programmers into using archaic conventions - object-oriented programers should hesitate. . . even avoid. . . using VB.NET.

[jmcilhinney]

That is different. My apologies. Just give me a minute to get my high horse off this soap-box... I think Microsoft would be happy if everyone migrated to C#, but it ain't gonna happen. A good developer will not be lulled, but removing the temptation is often a solution to preventing bad behaviour in any situation.

[Joe Mamma]

and please note that when I bash vb by tongue is firmly planted in my cheek! :)

[TheWizardofInt]

While I disagree with not using .Net, I have to agree that the module can lull you into a false sense of security

 

For example, you write a program that two people are using. You have a global variable called 'sGlobFilter', which is a perfectly good name for a global variable which holds a SQL expression which is sometimes used as a filter.

 

Unfortunately, it is global to the program. That means person 'a' sets it, and person 'b' is suddenly affected by it, always in ASP.Net and sporadically in Windows applications

 

Now it looks like your program doesn't work. Another drawback with .Net is that the documentation reads like an after-thought. If it isn't intuitively obvious to you how OOP works, then you are going to get these neat little surprises that survive your one-man-operation test environment and make it out into the field.

[bri189a]

All you newbies out there...you should read these posts about 20 times in a row!!!

 

btw nice example Joe of Singleton pattern.

[jmcilhinney]

The purpose of having a global variable is exactly that, to have access to it from everywhere. It doesn't matter whether you use a module, a singleton class or a class with all Shared members, you can still affect the single value of a global variable from anywhere in your application, so the same issues are applicable. If you don't want global access then don't use a global variable, of any kind, but if you do want global access then do. If someone is at the stage of creating a multi-user application then they should be at the stage of knowing the issues associated with global access to variables. Having a single database accessed by multiple clients is just an extension of this. Basically, good programming is good programming and bad is bad. If someone uses a global variable out of laziness then they deserve to have their application crash and burn, but if they truly need a global variable then the same issues apply, however they implement it.