Visual Basic .NET Nightmare or Guide to upgrading a Guru.
VBA lost & Found
Okay so maybe your not sure exactly what VBA is, so let's get a clear definition before we find out where it went.
VBA is the Base object for your VB 6 Application. It's an object in of itself and is called from Office programs to write the same style VB code you use in VB 6.
What this means is you can get things done the same way. When you do a VBA app inside of say a word document, the code is not compiled, it's stored in the source file your working with as Macro code.
If you have never realized this before, you can get a handle on it by going into VB6 then into the Object browser and find VBA in there. You'll also see VB, which is the object used to do the work that is not the same for an office app. VBA stands for Visual Basic for Applications.
Why is this important to me? Because it's what you have been coding with in VB 6 all along. And maybe you would like something to work that works in VB6 to use in VB7. At least until you graduate into a dot net master!
So where do I find VBA under .NET? Well it's now under the name space of Microsoft.VisualBasic. But this part is implied even in our .net app. Many of the functions themselves which are VB language specific can be written directly without addressing it within the name space, but you can alternatively get to them by addressing it in the name space. If you type in a VB function that does not automatically show it's function parameters, then it's most likely not implied, so preface it with the appropriate namespace.
You'll discover that a lot of functionality in Microsoft.VisualBasic is available in .NET from the system Object. Here's a similar object in both. System.IO and Microsoft.VisualBasic.FileSystem.
So in order to get to the FileSystem object (FSO) you can type it in without prefacing it with Microsoft.VisualBasic.
Things are not as simple as they appear though, so we want to master the differences before we move onto the truly new stuff. A simple open file and input routine has taken on a new shape. Let's take our standard VB 6 routine. This example expects a file MyText.txt to exist on your C drive with some lines of text saved in it.
|Private Sub Form_Load()
Dim MyData As String
Open "C:\MyText.txt" For Input As #1
Do Until EOF(1)
Input #1, MyData
tbInfo.Text = tbInfo.Text & vbCrLf & MyData
Pretty familiar territory. So what Has .Net done to it? Well let's just say they have enhanced it and then go from there. First off the commonality of the statement Open has to go, it's to generic. So they have changed it to be a bit more specific. .FileOpen is then new method under .NET and since they enhanced that they also rearranged the Function's parameters so that after writing "Open filename for Mode as #Number" a million times is no longer valid. And at some point we will feel that it's so old we wouldn't want to do it anymore anyway. Our old line of code is actually made of several keyword statements and operands that gets interpreted. What we have now is a Valid Method for opening a file instead. Reminder: Methods are functions belonging to objects.
So our FSO is now the provider of this method. So let's see how this looks under Dot Net then shall we?
sender As Object,
ByVal e As
System.EventArgs) Handles MyBase.Load
Dim MyData As String
FileSystem.FileOpen(1, "C:\MyText.txt", OpenMode.Input)
Do Until FileSystem.EOF(1)
tbInfo.Text = tbInfo.Text & vbCrLf & MyData
At this point we are familiar with the structure of a generated sub for an event. If your jumping ahead you can go back to the last page and get the details. Before we get into the code within, we want to take a quick look see at what arguments are being passed by System.EventArgs to see if there's anything we might want to play with. At the moment it's just got the generic set.
The .FileOpen Method has 3 Parameters in this line of code. The first being the file number, the second being the file and then lastly the mode. What's kind of both nifty and most assuredly annoying at times is the ability to scroll up and down through the specifics of the method's known parameters that can be passed. In this case it has only one and you can pass a few more parameters such as file access and record number.
Notice also that our Mode is an enum of file open mode types. If your familiar with enums, especially if you have created your own enum constants, then move along. If not then stay with me.
We all know that you can create variable named constants and assign them to a set value so that you can get to them by words instead of numbers. An enum allows you to group constants into a single collection and define them as an enum type and then call that type from somewhere else and get all the constants without trying to remember them. When you set a param in a function as one of these enum types it allows them to automatically be displayed for you when you get to that portion of the line of code and select them without typing anything at all. the only thing that really ever gets passed is the value of the constant selected.
Is the enum an Object? Just like any other variable but also with methods that only apply to an enum type.
Let's skip .EOF, it's pretty much the same thing. .Input is pretty much the same, but like .Open it's now a method of the FSO and not a command with operands. That makes it easier to pass your file number and your variable object. Now you might be wondering how does the data go into my variable if I pass it to the procedure. Even if your not I am going to shed some light here, because we have gotten used to having methods return a variable.
Our method for input is as so: Public Sub Input( _ FileNumber As Integer, _ ByRef Value As Object _ ) So the answer to this mystery lies in the keyword ByRef. As I explained before this allows the function (method) to access the variable directly in memory and change it without having to have it's own copy and having to pass that back.
Our last line of code within the do loop works the same way in both VB6 & VB7. Then we close the file by passing the file number.
Do I have to refer to these methods using the Object Name FileSystem every time? No, you can access them directly in your project because it part of the VB language.
Now let's attempt to do the same thing using System instead of FSO. There are many reason we would want to do this, but our number one reason is we want to master dot net.
However let's keep in mind, if time is pressing and your still struggling with something simple that's become part of your VB .NET Nightmare in mastering, you can always resort to VB's runtime objects just to get by. The runtime is part of the .NET frame work and your program will still work with the expected performance of any other VB 6 app.
Now let's take a look at dot net code for the same ability to read a file. For this code we are going to add a button to call our routine so that we can see both sets of code in our app.
sender As System.Object, ByVal
e As System.EventArgs) Handles
Dim MyReader As System.IO.TextReader
MyReader = System.IO.File.OpenText("C:\MyText.text")
tbInfo.Text = MyReader.ReadToEnd
|MyReader = System.IO.File.OpenText("C:\MyText.text")|
The next object we use is the File Object. In the description for it it says: Provides static methods for the creation, copying, deletion, moving, and opening of files, and aids in the creation of FileStream objects. Our TextReader object is a FileStream type object.
Okay so what does Static mean here? What it's signifying is that you do not have to create this object to use it's methods. It's provided as is for you to use. You can at the same time assign it to an object variable and produce the same results. You do not have to create the object explicitly, so you do not have to set it or create it with the New keyword.
Is the File Object implied? No, you must address it's name space. If you intend to use the file object many times you could set it equal to a variable and call it's methods from your Variable name. You can do this with one line of code like so.
|Dim MyFile As System.IO.File|
The Method we are using is .OpenText, you'll see a few more different open statements after your dot. So What does this mean in the way that it's different than our FSO style? Well we are indicating text as our type of data to be accessed in our open method. This replaces our "as mode" in VB 6 and our Mode Type using FSO and indicates we want to handle the data as text and not binary. Also with our statement we are setting our TextReader Object to the file specified, which means we do not need to access the file via a file number. Our object takes care of that for us. And this makes it easy for us to not get our numbers mixed up for open files.
Now that we have our file open and assigned to an object we can access it with our TextReader object. our method of choice right now is .ReadToEnd. We are expecting our file to be pretty small for this adventure and we can just stream in its entire contents and assign it to our textbox's .Text property all at once.
Then we will call the .Close method. This does more than just close the file, it disposes of our TextReader object altogether. Which means that when the button is clicked again the whole routine is repeated as fresh.