MS made F2 point to Object Browser, just like in VB6. It's the quickest way
to learn the .Net framework, and what to call to do the same thing that you
were doing in VB6.
In VB.Net, "all" project files use ".vb" extension. The first few lines tell
you if it's for a Module/Form/Class, etc. It maybe confusing to see "Public
Class Form1", because it says it's a class, but that is true even for VB6.
In VB6, Form, Class, UserControl were called Object Modules, while ".BAS"
files were called Standard Modules. Standard Modules still exist in VB.Net,
but some; even in VB6 don't recommend their use if you can put the code in a
Class. Classes help divide your code into manageable components that don't
interfere with each other, and each is responsible for the functionality it
manages.
If you use standard modules, then at some point you find that you need to
turn some variables into global variables so they can be accessed by the
other modules, but this would introduce data integrity problems, or variable
integrity as I call it. Imagine that you have a group of related variables,
like an array, and a counter variable, or flags that must be set or checked
in a UDT before using other variables in the UDT. If you use standard
modules, you might find yourself that you are checking the related variables
everywhere you are accessing them, and you would introduce bugs if you
forgot once to check them somewhere, perhaps when you come back to the
program after doing something else for a year, and you added more code and
forgot that checking a flag is needed. Putting the checking in one routine
and calling it from everywhere helps, but you will still find that any
routine can call any other routine, or accessing any variable is an
invitation to bugs, which is called "Spaghetti". Putting things in classes
helps insuring that the integrity of the variables or data is maintained.
Plus you could reuse routine names, for example, you can have
oStudent.Search(), and oTeacher.Search(), which makes your code easier to
read.
As for "Namespace", it's a concept or keyword that at least was introduced
in C++ in the 1990's. It's basically used by the compiler to collect the
symbols and putting them in a basket with a certain name on it so the names
collected don't interfere with what another coder is writing. If you have
multiple developers, they can use DevA, DevB, etc. namespaces so if they use
the same names, there is no conflict.
If the name space you want is too long, like "Windows.Forms...", etc., you
can use "Imports" statement to allow the names in that namespace to be used
without the namespace-name as an explicit qualifier. For example:
Before:
Windows.Forms.MessageBox.Show(...) ' Somewhere in the file
After:
Imports Windows.Forms ' At the beginning of the file
MessageBox.Show(...) ' Somewhere in the file
This allows you to use anything in "Windows.Forms", and your line is
certainly shorter. However, in some cases there could be something in that
namespace that conflicts with something you are declaring(and you get
compilation errors). In that case, you can use an alias for that name space,
so you just type the alias, not the whole name. For example:
Imports WF=Windows.Forms ' At the beginning of the file
WF.MessageBox.Show(...) ' Somewhere in the file
Imports Statement
http://msdn.microsoft.com/en-us/library/7f38zh8x.aspx
In C++/C#, they use "using" keyword to accomplish the same effect.
