Should you really care about My?
I have to admit that My was not in the top three features of Visual Basic 2005/Visual Studio 2005 that got me excited when I first started looking at the list.
In fact, dare I say, I might even ranked it toward the bottom. Let me explain, I have been working with .NET since PDC 2000. After 5 years of living with the framework day in and day out I tend to know it pretty well. While in some instances it makes me write more lines of code then I care for with my understanding of it that is not really a big productivity hit.
It is in this context that I looked at My and said, “way to I really care about this as a developer?”
Then I used it.
I have taken a rather extensive and complex application with Visual Basic 2003 that I wrote for a customer in my life before Microsoft and I ported it to 2005. I wanted to make sure I understand everything our customers where going to experience and how it felt to really port a line of business application to 2005.
My has now become my favorite features, even knocking off the return of Edit and Continue in the list.
It is so handy and easy to use. Let me give you some examples:
I was updating some code that took a stream and wrote a file to the hard drive, later it would use a bunch of these files to zip together and send out an attachment to an email. In V1.0 of the application the file is written to a specific directory on the hard drive that the setup program created.
Since this application is installed on hundreds of doctors PCs in numerous hospitals this was not always a great solution so in my porting I figured I would make a few updates to get the full experience of 2005.
In V2.0 I wanted to write the files to the Windows temporary directory. This directory can be in lots of different places depending on the version of windows and how it was installed so in code when I used My I could simply say:
My.Computer.FileSystem.SpecialDirectories.Temp
My automaticly gives me the Windows temp directory. There was no need to call out to the Win32 API to discover this location, no reason to write any other code.
After I have created the zip file I want the zip to be written into the My Documents folder. This path changes for each user, with My I simply say:
My.Computer.FileSystem.SpecialDirectories.MyDocuments
My automaticly gives me the My Documents folder for the user.
It’s not just file paths. At another point in my code I wanted to play a wave file located in the applciation directory by the install program. One line of code with My took care of it all for me:
My.Computer.Audio.Play(My.Application.Info.DirectoryPath & "NewAlert.Wav")
Or when I wanted to play a system sound at the end of a file upload:
My.Computer.Audio.PlaySystemSound(System.Media.SystemSounds.Asterisk)
All of these things were possible before My but as I have discovered My I find I use it more and more and write less code as a result. Granted it made me feel nice and smart to know the complex set of base class library calls to make to play a Wav file out of the applciation directory path but in the end writing less complex code to do the same thing is even smarter. Remember most customers pay developers to solve business problems with good quality solution, not to write large amount of code if they don't have to. Less code that you have to write is less bugs, less development time, less testing, and faster time to market.
These are a few real example of using my and some very simple things you can do with it. In the near future you will see a new series of content on the Visual Basic Develeoper Center that digs into My, the great features already built in and the ability to extend it to make your custom tasks even more productive. If you have not already played with My I encourge you to try it out and watch for the coming content on it.