borderAndreaVB free resources for Visual Basic developersborder

borderAndreaVB Visual Basic and VB.NET source code resources - Copyright © 1999-2007 Andrea Tincaniborder

AndreaVB Home | News Home | Forum Home | Downloads | Register | Search | PM | Profile

Previous Topic (Managing INI files)Next Topic (FIX to Winsock freezes Visual Basic VB 6 and windows XP (Winsock Fix TIP)) New Topic Post Reply
AndreaVB OnLine : Articles and tutorials : Adjusting your scope - A look into variable scopes in .NET
Poster Resource
fabulous
Level: VB Guru


Registered: 03-08-2002
Posts: 439
icon Adjusting your scope - A look into variable scopes in .NET

Declaring variables is a very fundamental requirement in programming and you cannot go anywhere without it. For those of us who came from previous versions of Visual Basic, .NET presents a new set of issues with our variables.

This is not to say that the old way was flawed, no, but there are new options available to you now. One thing that you must become familiar with is the introduction of new levels of scope, and this is what we will be focusing on in this article.

What is variable scope?

The word scope in this context means the extent to which a variable can be seen/used inside a program. If you have ever tried to access a variable you placed in one module as private from another module, you would have failed to do so. This is because of the scope level assigned to that variable.

Visual Basic has in the past had the following levels of scope, Public, Private/module-level, local and Friend. I will first describe these briefly and then move on to the new levels that have come with the advent of .NET.

Public

A variable declared as Public can be used from anywhere within a project, and without, if this is a .DLL. Now that everything must be in a class, the best way to include a property without any validation is to declare a public variable of the desired type. If this is placed in a module (Module), you can use it from any class or form as if it was declared in the current code module. If, however, it was in a class or form, you will need a reference to an instance of the class but you still can access it.

Private

As the name says, this is private. Private variables are only accessible in the code module they are declared in. It is for this reason I prefer to call them module-level variables. No matter what you do, code outside the variables module can never access these variables.

Friend

A friend variable is like a public one in every way until you move outside the project. When making a DLL (or Class Library as they are now known), there are times you want something to be available throughout a project. However, you may not want outside projects, the client applications, to use these features. The way to do this is to declare it as a friend. A friend variable can be used within a project in exactly the same way a public variable can, with the exception that client-applications know nothing about the friend.

Local

Local variables are variables that are declared within a method. These variables are only available within that method. This is why you can declare a scratch variable called ‘lng’ in all your methods without experiencing or causing any problems. We can do this because each method has a local copy of this variable and it won’t interfere with the local copy of another method.

These scope levels are still available in .NET so I will not explain them in terms of .NET. Public is still public and we have not lost our privacy neither have we forgotten our friends.

New scope levels

.NET has come with some new levels. In previous versions of Visual Basic, you could declare a variable as a friend. However, once you mentioned that a variable was friendly, it became everyone’s friend. This was not entirely bad, but in some cases you would not have wanted code in some modules to access the variable. With the current version, not only can you specify who your friends are, you can protect them as well. The new levels are; Protected, Protected Friend and block level.

Protected

The introduction of proper inheritance had to bring with it some changes in the way we think and code as VB developers. The inheritance we had in the days of .OLD was known as ‘Interface Inheritance’. This meant that if there was a class that provided features you wanted to extend, you would have to specify that your class Implemented this class’ interface. You would then write code to delegate all expected interface methods to a private instance of the base class and then write code for your features.

This was cumbersome at best. Now, all you do is tell VB that your class inherits from a particular class. Then you just add code for your new features. If you are the author of the base class, there is stuff that you would only want subclasses to access. You can do this by saying that it is protected. A protected variable can only be seen and used by subclasses of the class that defines it.

Protected Friend

This is the friend I referred to earlier. You like this one so much that you protect it from outsiders. What do I mean? When coding a .DLL, you may make a base class and now want subclasses coded outside your .DLL to access certain features of this base class. This could be because of security reasons. A Protected Friend variable is available to subclasses in your app but totally invisible outside, unlike a Protected variable.

Block

The last level I defined was block level. Please note, this is not a formal name. Inside a module you could not declare two variables with the same name in previous versions of VB. In .NET however, you can do this as long as they are in different isolation/logical blocks. By this I mean inside loops, decision blocks and the like. This level requires some sample code to enable you to understand:

Dim a As Integer
For a = 1 To 10
  Dim b As Integer
  b = b + a
Next
Dim c As Integer
Do
  c = b + a * (c + 1)
Loop Until c > 200


The above code will throw an exception. This is because you tried, (yes you, don’t try to blame it on me), you tried to use the variable ‘b’ inside the Do..Loop before declaring it. What Yes, you haven’t declared it. Did you think you could get away with using the one declared inside the For loop? No ways. That was for that loop. If you want it again, well, you have to declare it again, or declare it outside a logical block. A logical block may be one of the following; Try, Catch, Finally, Do, If, Else, ElseIf, While, Select Case, and Case.

A variable declared inside a Try block is not available to the Catch and Finally blocks. The same holds true any other way round. You cannot use a variable declared inside an If block from within the Else, or one of the ElseIfs. This means that you can declare variables with the same name in the same method and with different types as long as they are declared in different logical blocks.

Conclusion

I was tempted, both by myself and a few colleagues to include Shared but I figured that it would need an article of it’s own if it is to be introduced to a new audience.

Armed with this information, I urge you to go forth and wage war on the problems that stare our customers and clients in the face. Let’s hope you can use this wisely. Happy coding.


[Edited by fabulous on 27-06-2004 at 10:03 AM GMT]

____________________________
My boss is a Jewish Carpenter (Jesus Christ)


Brain Bench Certified VB.NET Developer

25-06-2004 at 04:21 PM
View Profile Send Email to User Show All Posts Visit Homepage | Add Comment
johnedw
Level: Sage

Registered: 15-08-2004
Posts: 50
icon Re: Adjusting your scope - A look into variable scopes in .NET

Very nice, I really enjoyed this article


____________________________
Today is a new day, in
a world OF CODE!

15-08-2004 at 10:39 PM
View Profile Send Email to User Show All Posts ICQ | Add Comment
MacsPlace
Level: Trainee

Registered: 21-02-2005
Posts: 1
icon Re: Adjusting your scope - A look into variable scopes in .NET

I am a C++, Java developer. I recently began learning VB.NET with no prior knowledge of "VB.OLD". It floors me to think that the vb commnuity has managed all these years without things like block scope.

You mentioned before that vb could implement in the old days, but not inherit. These are really two different things. Did vb loose the abilty to implement when it gained the ability to inherit? or did I misunderstand?

In my mind implement means to "be refered to as" For instance, if you had a money class, and you had a coin, the coin could implement money by defining all it's methods in coin.

where as inherit means "is a". For instance, a dog "is a" animal. The dog could be even be an (and most likely will be) abstract class.  

21-02-2005 at 05:09 PM
View Profile Send Email to User Show All Posts | Add Comment
fabulous
Level: VB Guru


Registered: 03-08-2002
Posts: 439
icon Re: Adjusting your scope - A look into variable scopes in .NET

Hi MacsPlace,

Sorry for getting back to you so late. Been away from the net.

VB.NET did not lose the ability to implement, it can now do anything any OOP language can do, with the exception of Operator overloading. This ability is present in VB.NET 2005, but  I imagine the reason it was initially left out is that the average VB programmer, and indeed most VB Gurus (who know and are good in other languages) do not want or need this ability.

You analogy about inherits and implements was correct. Hope you liked the article.

And for johnedw, glad you liked it. Happy coding

____________________________
My boss is a Jewish Carpenter (Jesus Christ)


Brain Bench Certified VB.NET Developer

29-04-2005 at 03:44 PM
View Profile Send Email to User Show All Posts Visit Homepage | Add Comment
AndreaVB OnLine : Articles and tutorials : Adjusting your scope - A look into variable scopes in .NET
Previous Topic (Managing INI files)Next Topic (FIX to Winsock freezes Visual Basic VB 6 and windows XP (Winsock Fix TIP))New Topic Post Reply
Surf To:


Not Logged In? Username: Password: Lost your password?
Partners: Download Actual Software | Free Software Download
borderAndreaVB free resources for Visual Basic developersborder

borderAndreaVB Visual Basic and VB.NET source code resources - Copyright © 1999-2007 Andrea Tincaniborder