Visual Basic Guide to Upgrading a Guru.


Page 2

Class Attendance.

Do we completely understand Classes and Objects yet? I know switching between VB versions I can still think Old VB while in Dot Net and vice versa. Maybe I should clarify, Old VB as in VBA, Visual Basic for Applications, which you can still find behind office apps up to version 2003. So let's see if we can shed a little more light on this subject, because your going to need it as VB8 has some old happy coding coming up from Old VBA.

Class Objects: These Beasties are Objects of code that are created from base class files. You use the code in the class by instantiating it as an object. This creates a new object for you to use, make changes to and eventually discard.

Interpreted Code: VBA has it's own class object. Let's take a look at it. Going into the IDE with our test solution open, let's click Object Browser. You should open to an unexpanded list of objects. Notice right there at the top is Microsoft.VisualBasic. This is where VBA ended up for what it is under dot net. And we do not have to instantiate it, because it is loaded when our VB apps are run. It is responsible for interpreting our code as it were to give us...well...our basics of programming. Let's test this then, shall we?

Low and Behold the immediate windows has returned! All hail...wait...wait. Just open it. Debug---> Windows--> Immediate Window. Now tack it there. You may have seen something under 2003 that seemed to be the same thing, but alas, it wasn't. What we have here is what we had under VB 6 and it works the same way. Let's put a single line of code into it.

Looks pretty simple. Just type it and hit enter. Bam, it runs! But what does it all mean? Is this why it's not dot net anymore? Maybe. But it's not without it's rules. If you try this under 2003 you get nothing, even the line of code didn't work under 2002 (IIRC), I seem to remembering having to have a more formal reference to the message box object. So is it interpreted or is it an object? Well let's search for it in the object browser. And here we have it.

Microsoft.VisualBasic.Interaction.MsgBox(Object,[Microsoft.VisualBasic.MsgBoxStyle],[Object]) As Microsoft.VisualBasic.MsgBoxResult

The line is blurred because we don't have to actually create the object to use it. Therefore our simple line of code is interpreted by VB and it does create an object, it does it automatically. So it's kind of both. How about some simple math? Msgbox(1+1) pop that in the immediate window and see what that does. Is this an object? No it's not, what happens is the VB Object interprets our simple line of code and passes it through a function. Mainly addition, which computers are very famous for doing.

So basically VB is running while the IDE is running. And it's ready to interpret lines of code that you put into your code window and the immediate window. This makes Migrating VB 6 apps just a slight bit easier. As well as giving us back some more familiarity. So long as we don't take it to far. Like I did with forms.

Yes we've been over this, but let's make the statement again. Forms are objects and do not belong to VB. Controls and Containers are objects that no longer belong to VB. In fact very few things do, except there a few more VB Objects under Dot Net 2.0. Everything other than VB that shows up under Microsft.VisualBasic is new. Notably Devices and FileIO. But we are more than likely not to call them up directly. Only VB is going to be interpreted. These new things are objects. So what's the difference? Unlike the rest of them, these are liken to VB in that we do not have to instantiate them to use them. more like Old VB, maybe?

'My' Namespace: Basically this is your keyword to get to all the things you can do under VB without creating object instances. Under VB as in VBA you have the old standby File System Object. You could write code that was interpreted that handled files & folders. MKdir for instance. if you've done previous lesson under 2002 you'll remember how I showed you how to use the system.IO object to do things that we did under VB as interpreted lines of code. Well those lines are back, but let's not get stuck, because there are new things to pursue. Such as My.Computer.FileSystem. Well how new is it, really? Well it has the ability of VB ease with the power of the System.IO. In other words all those things you do under IO, which involves object creation first, can now be done by interpreted lines of code using the New VB Object FileIO.

Did the train just jump the track? Seems like it, first it's VB and now it's My.<Stuff> The truth is it's the same stuff under VB these two namespace references are equivalent.


Those are using the FileIO objects belonging to VB. This old standby MkDir("D:\Wow") will also work! This is using the File System object belonging to VB itself. And you can code directly to it, err...again! (Just checked, this also worked under 2003, but not 2002, IIRC)

Not excited yet? Try finding CopyDirectory under Old VB, it's not there. It's under System.IO though and we've had that. Maybe there isn't anything to get excited over, yet. Because now we have a few more ways to do the same thing. The important thing is to note that the VB Object that contains the FileIO object has been upgraded and the easiest way to get to it's power is the My namespace. And here we have something totally new: Microsoft.VisualBasic.FileIO.SpecialDirectories. Or

Pop that into your immediate window. I can say it wasn't just too long ago where I was coding in VBA under Office where having this would have been completely handy. Under old VB FSO there is just no way to get the current desktop of the current user, which does bring us to some more cool things under My.<Stuff> Like My.Computer.Name.


Page 3