BA 371 - VB.NET Introduction

The material presented in these and the following labs represents a short course in VB.NET for people with previous (C) programming experience. It only covers the basic aspects of VB.NET and leaves many issues undiscussed.

The labs are self-guided in that both questions and their answers are provided. It is really up to you to learn this material and get the basic aspects of this language under control.

Although you could 'run' through this lab quickly by cutting the various segments of code from these pages and pasting them into the VS.NET IDE, you would learn very little doing so. We therefore strongly!! recommend that you study this material while exercising it.

• Carefully read the examples, questions and answers.

• Cut and paste code, but carefully read and try understanding the code before you compile and run.

• Try answering the various questions you encounter yourself before checking out the answers.

• Experiment with the codes! Don't take them for granted. Play and experiment with them and try to understand the resultant behavior.
  

Some Basic History:

• 1964: J. Kemeny and T. Kurtz (Dartmouth College) designed BASIC as a stepping-stone to languages such as FORTRAN or ALGOL.

• 1970s: Bill Gates and Paul Allen developed a BASIC interpreter for the Altair
ul>
• 1970s-1990s: Quick BASIC --> Visual BASIC (VB) --> compiled language
• Now: VB.NET:
• .NET by Microsoft Corporation: Unification through layering:
• .NET Framework:
• Common Language Runtime (CLR).
• Foundation classes.
• .NET servers.
• .NET devices.

• Similar approaches:
• CORBA (Common Object Request Broker Architecture) by Open Management Group.
• J2EE (Java 2 Enterprise Edition) by Sun Microsystems.

First VB application: Hello World...:

Public Class Hello

    Shared Sub Main()
        System.Console.WriteLine("Hello World...")
    End Sub

End Class


1. Store as ASCII (text) in file; e.g., foo.vb
2. Start a command-line (DOS) window off of the Start --> ... --> Microsoft Visual Studio .NET --> Visual Studio .NET Tools --> VSt.NET command. (note!!! a regular 'vanilla' command window won't work).
3. Compile and link the source into an executable:

   >vbc foo.vb /target:exe

4. run the executable:

   >foo

Visual Studio.NET Integrated Development Environment (IDE)

1. Start VS.NET.
2. Using File-->New-->Project..., set up a new Console Application. Take note where the project gets saved (Location). Note that the IDE/compiler/run-time environment works a lot faster when you create projects on the local (e.g., c:\temp) machine. If you choose to do so, make sure you copy your work to a private space at class end.
   
3. Notice the project's components in the Solutions Explorer window. Change the name of the .vb source file from Module1.vb into foo.vb.
4. Notice that in the Solutions Explorer window, a project is part of a solution. In VS.NET, solutions are complete, integrated software systems which may contain several executable files, the source codes of which are managed in projects.
5. Erase the dummy source code from the edit window, and replace it with the code from the previous exercise. Save all.
6. Close the project and terminate the IDE. Then startup the IDE again and make sure all components are still in place (reload your foo.sln project file project from File --> Recent projects. Double-click on the foo.vb source file entry in the Solutions Explorer window to load the file into the source code editor window. If this does not work, carefully go over steps 2-5 again.
7. Compile the project and build the executable (Build --> Build foo). In the Task List there will be an error (if you do not run into this error, make sure that you started a Console Application, not a Windows Application):

   Error! Sub Main was not found in foo.Module1

   Reason: no top class known. In Solution Explorer window set foo --> Properties --> Common Properties --> General --> Startup object to Hello or Sub Main).

8. Recompile and notice how foo.exe is created in ...\foo\bin directory
9. Start a (normal) command-line (DOS) window, cd to the ...\foo\bin directory and run the executable:

   >foo

10. You may run the executable directly from the IDE (Debug --> Start without Debugging). Do you notice anything different? Can you explain this difference?

Calling a subroutine (function in C):

1. Replace the code in foo.vb with the following:

Public Class Hello

    Shared Sub Main()
      System.Console.WriteLine("Hello World...")
      System.Console.WriteLine()
      do_this()
      System.Console.WriteLine()
    End Sub

    Shared Sub do_this()
        Dim first As Int16 = 32767
        Dim second As Int16 = 0
        Dim result As Int16

        result = first + second

        System.Console.WriteLine(CStr(result))
    End Sub

End Class

• Code contains a subroutine (a 'function' in C) do_this().
• do_this() declares three 16-bit (2-byte) integers. (Overview of VB data types).
• first is set to 32767.
• second is set to 0.
• result is used to store the result of first + second.

• Result gets converted into a string (CStr) and handed over to WriteLine() to be written to the console.
• do_this() is called from Main().
• For C/C++/Java programmers: notice how do_this() is not declared void for either its parameter list and its return value.

2. Compile and run from the IDE.
3. Now modify the program so that second is initialized to 1, rather than 0.
4. Compile and run. What do you observe? (Select 'No' when asked to specify a debugger) (What behavior would you expect in C?).
5. Change result into an Int32, recompile and run.
6. Also change either second or first into an Int32. Recompile and run. Can you explain what just happened?

Functions and Subroutines in VB.NET:

• Notice how in the above code do_this() is called from inside Main().
• VB.NET offers two ways of coding such sub sections of code (in C, all sub sections are functions):
1. Subroutines: execute pieces of code, then 'go away':

   Sub my_sub()
        some code
     some more code
   End Sub
   

2. Functions: execute some code and return a result to the caller as they go away:

   Function my_function()
       some code
       some more code
       return some_value
   End Function

   • Example:

   Public Class Hello
   
       Shared Sub Main()
           dim my_var as int16
   

           System.Console.WriteLine("Hello World...")
           System.Console.WriteLine()
   
           my_var = do_this()
           System.Console.WriteLine(CStr(my_var))
       End Sub
   
       Shared Function do_this() as int16
           Dim first As Int16 = -99
           Return first
       End Function
   
   End Class
   
   

   • For C/C++/Java programmers: To make things a little weird, by default the VB.NET compiler does not at all complain when functions do not return anything or when the caller does not assign the value of a function.

   This begs the question of why to use subroutines at all??
   
   Answer: BASIC has always been a 'permissive' language; i.e., lenient on type checking. The new .NET approach requires strict type checking (as do C/C++/Java). To enforce this:

   • From now on, !!! ALWAYS have the following lines at the top of your code !!!

   Option Strict On (on by default in VS.NET 2003)
   Option Explicit On

   • With these options set, modify the above program such that the function do_this() returns an Int32. What do you observe? Try the code without the options set. Do you understand the resulting behavior?

Passing parameters by value (ByVal) or by Reference (ByRef):

• Suppose we have a variable Short foo in Main() and we want the function or subroutine do_this() to multiply its value.

• Try:

Public Class Hello

    Shared Sub Main()
        Dim my_var As Short = 10
        System.Console.WriteLine("Hello World...")
        System.Console.WriteLine()

        do_this(my_var)
        System.Console.WriteLine(CStr(my_var))
    End Sub

    Shared Sub do_this(ByVal foo As Short)
        foo = foo * CShort(10)
    End Sub

End Class


• What do you observe?

• Notice how strict type checking forces you to convert '10' into a short using Cshort(10).

• foo is not multiplied by 10 when printed out in Main(). Cause: When passing a variable by value (ByVal), only the value of the variable is passed, not the variable itself (a memory copy local to the function/subroutine is created) (default in C).
  

• To access the passed variable itself, pass by reference (ByRef) (pointer/address in C).

• Notice that regardless how passed (ByVal or ByRef), the variable names in the caller and the function/subroutine can be different. ByRef implies that memory is not copied (only the address (pointer) is passed); the name of the local reference to that memory is immaterial.