Global varible

S

shankar_it

Freshman
Joined
Jul 6, 2005
Messages
46
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?.
 
I am using this in VB.net windows form


shankar_it said:
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?.
Click to expand...
 
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.
 
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.


jmcilhinney said:
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.
Click to expand...
 
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.
 
Thank you for your help

Machaira said:
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.
Click to expand...
 
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.
 
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 -

Code: 
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:
Code: 
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
 
Joe Mamma said:
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 -

Code: 
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:
Code: 
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
Click to expand...
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.
 
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.
Click to expand...
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. ;) )
 
Joe Mamma said:
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.
Click to expand...
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.
 
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.
 
Joe Mamma said:
As I said along time ago. . . VB6 made alot of poor programmers.
Click to expand...
I agree, but this isn't necessarily the case here.
Joe Mamma said:
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.
Click to expand...
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.
DiverDan said:
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.
Click to expand...
"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.
 
Machaira said:
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.
Click to expand...
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.
Click to expand...
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:

Code: 
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. . .
 
Last edited:
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]
 
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.
 
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.
Click to expand...
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.
 
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.
Click to expand...
Click to expand...
A Posteriori. . .

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

Because it can lull programmers into using archaic VB conventions, object-oriented programmers should hesitate to use VB.NET. :p
Click to expand...
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.
 
no I am saying. . .

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