If you run the following in C# you will see that only the "Was Empty" is shown:
C#:
if(this.textBox1.Text == null)
MessageBox.Show("Was null");
if(this.textBox1.Text == String.Empty)
MessageBox.Show("Was Empty");
this.textBox1.Text = null;
if(this.textBox1.Text == null)
MessageBox.Show("Was null");
if(this.textBox1.Text == String.Empty)
MessageBox.Show("Was Empty");
I think your reasons for saying you can set a TextBox's Text property to null is because it allow you to pass it, but internally it say's it's still String.Empty, not null. Since VB treats String.Empty = Nothing (or is it Nothing = String.Empty? or both?) then I believe the similiar above in VB would show both message boxes before and after the click. I don't know CLR though so I'm admitedly making an educated guess on that. And thanks for the further detail of CType/DirectCast...I always forget that it does converting too, I soley use it as an equivelant to:
C#:
MyNameObject mo = SingletonClass.GetObject() as MyNameObject
The reason I shoot down VB6 functions is because they are VB6 functions. They are deprecated in my book even if not officially. Why? Well to give an example I work with a lot of RPG programmers. They have a few old dogs who are still using RPG 2 and 3, they currently for the most part do RPG 4 and are trying to move to ILE (and switch over to Java on new programs concurrently). Unfortunately IBM supports syntax all the way back to RPG 1. And it's really funny to watch these new programmer's complain about the code some old dog wrote in RPG 2 that could be done much cleaner in PRG Free Form. Then to watch these old dogs totally lost when trying to debug a program written in the 'newer' language (because they never learned RPG 3 or 4 or ILE because since it was always backwards compatable they never had to). See anything similiar? He can learn it now, or he can learn it later...the longer he takes to learn it, the worse off he'll be IMNSHO. Backwards compatiability on a DLL is great, on a language I think it's asking for trouble if it's any more than 1 generation...and that one generation that is backwards compatable should have everything marked as deprecated.
Finally, I'm sorry but thinking of 'your' needs, and 'what works best for you' is a sure way to have something that isn't supportable and isn't maintainable in a corporate environment. Supportability and how easy it will be to make future enhancements by people who aren't familiar with the program have to be at the foremost of your mind (and yes documentation is a large part of that), and in a corporate envrionment you have about a 10% chance of supporting something you wrote. VB6 isn't taught in colleges around here, .NET and Java are...and they don't teach CType, CDbl, or CSng...so when these kids come in they maybe able to figure out what it means, but they're going to wonder why they're using it (kind of that whole RPG 2 thing)...go 5 years into the future and this could be a big problem.
If your sole desire in life is to write your own personal programs as a hobby; do what you like...use GoTo Line 12 if the language supports it and poor some Ragu over that spagetti, but if you want to work in a corporate enviornment - IS or ISV then you need to lose that 'what works best for you' attitude real quick and follow the corporate standards.
If your corporate standards are to use CSng and such...then go for it...but at my corp that's against the standards and I, on a personal level, agree with those standards. Sure, it does cause me to write extra code when working with arrays and a lot of other things when I'm doing VB.NET that I could be lazy and use old VB6 functions for, but then I don't mind because I know a Java or C# programmer can look at it and support it and modify it without have to figure out the VB6 specifics. This means when it comes to code reviews and technical design documents I don't get asked any questions, which means I get a out of meetings quicker, which means I'm a happier person.
