“The solution to computer illiteracy is to learn, not to cut the capabilities of the system for everyone. That’s the triumph of ignorance.”

Is that really the point? Whatever the developer decides is what’s right? People should adapt to the computer, no matter how poorly designed, rather than adapting the computers to people?

To me, the point of pushing the boundaries with technology, is to make the technology easier to use. In face, that’s the underlying theme of my entire career. Using my knowledge and skill to make someone else’s job easier. Making my job easier.

The DataGridViewComboBoxCell won't allow values to be entered in the cell if they are not in the Items collection. Since I can't modify the Items collection if the DataSource property is set, I add value of the cell that's causing the DataError to the DataSource for the combo box. Since it doesn't throw anything sensible like a ComboBoxValueNotInItems exception, and it doesn't raise something nice like a "DataBinding" event or an "ValueNotInItems" event, or even an "Validating" event, I have to trap the System.ArgumentException. This may come back to bite me later. For one thing, will I ALWAYS set the Datasource to a DataTable object? What if I use another object for the data source.

I found a post in the MSDN forums where they talk about accepting user input in the DataGridViewComboBoxCell which isn't in the cells Items collection.

For 1 year, starting Nov 7th, you can download and use any of the Visual Studio Express Editions for free.

I often said the only reason I'm experimenting with Cocoa development is that XCode comes with OS X for free. If I had to pay $400 for XCode, I wouldn't be using it. In fact, Xcode for free is part of the reason I finally took the plunge and bought an Apple machine. I get to tinker for free!

Now, Microsoft has the chance to prove that they really get it by providing all of the free express editions ON THE VISTA RELEASE DVD. C'mon Microsoft, plant the seeds for a whole new generation of developers for your platform.

Make sure that the default namespace for your Visual Studio project is the same as the class you are trying to access resources embedded in your .resx files from. We kept running into problems if the two were not the same in one of our custom web controls. It appears that when .NET puts your resources into the manifest of your Assembly, it associates them with the default namespace of the project somehow. (I'm not entirely sure how this is all accomplished. I'll see if either I or my co-worker can hunt down someone at MS who can give me a better explanation.).

The error you will get is long and generic, something about how the resource could not be retrieved for the given culture. I've just re-imaged my work machine, once I finish installing everything I'll replicate the error and the solution, posting the code and error message here.

For me it's all the simple stuff. I don't know how many times I've typed in string _name; in a VB.NET class and gotten an error.

What really gets me though is all the damn TYPING I have to do when I'm just trying to inherit from a class or implement an interface and define out it's methods. Thank god the IDE will fill in the interface methods for me. Even when it does, there's no consistancy. I hit tab in C# but in VB.NET I have to hit enter. Then I have to go delete the linebreak that hitting enter puts in. That's annoying.

All of the shadows, implements, inherits, notinheritable, blah, blah, blah, etc... crap really keeps me from enjoying programming in VB.NET. Too much typing.

Paul Vick chimes in with some well thought out reasons why migrating VB6 to Visual Studio.NET isn't a good idea. My favorite quote:

"To?start with the second point first, to those who think we should?integrate VB6 into the current Visual Studio shell, I can only offer the perspective of a developer whoís worked in both codebases: best of luck. "

His other points addressing the idea of creating a non-integrated version of VB make sense too and extend what I said in my first post. How much longer do the VB6ers want? They've had 5 years to migrate their code. The need to migrate isn't something that just popped up. Should Microsoft spend 4 years integrating "VB.COM" into Visual Studio.NET or 2 years shipping an update to VB 6? If they do ship a stand-alone version, what new features should it include? Generics? Wouldn't that just be giving the VB6ers a placebo? It doesn't cure their problem.

On the other hand, this petition does provide a centrally located "do not hire" list.

I'm with Richard and others on this one. Just because VB6 != VB.NET doesn't mean that VB.NET should provide backwards compatibility. It's not like Microsoft didn't TELL you about this. It's not like at PDC 2000 they didn't say "VB.NET is not compatilble with VB6". That was FIVE YEARS AGO PEOPLE. You are just NOW getting around to "protesting" VB.NET and the abandonment of VB6? I was doing primarily VB6 development at that time and I remember sitting in the sessions at PDC 2000 thinking, "Man, I can't wait to dump VB6 and re-write my stuff in VB.NET and C#". Hell, the VB6 people should be ECSTATIC that MS isn't going to be updating their environment. Visual Studio 6 is more stable that Visual Studio.NET 200x. Some people prefer using Visual C++ 6.0 over Visual Studio C++.NET (or whatever it's called).

So while I'm sympathetic, I'm not THAT sympathetic. There was less complaining when Java went from version 1.2 to version 1.3 and half the GUI code broke as a result. Just hike up your pretty pink pinafores and migrate your code to VB.NET. Those of us that might have to maintain your VB6 code at some point will be eternally grateful.

Mikhail says he's not really in love with camelCasing. I use it all the time and I did before I started coding against the .NET Framework. His example makes sense, although anyone who's naming their vars "a","b" and "c" should be shot.

My favorite example when I'm arguing for the use of pseudo Hungarian (or full Hungarian) is DateTime vars. I work in the web world so I'm always using the ToShortDate or ToLongDate methods on DateTime variables. If I'm passing around a DateTime string what should the var be called? shortDateTimeString? or just shortDateTime? That's not really descriptive, lets use startDate. Does startDate return a DateTime or a String? Should I name the var startDateShortDateString? Wouldn't strStartDate be better than startDateShortDateString? The "hover over the variable in the IDE" trick only works if you are in the IDE and if the IDE is working (I've had to restart Visual Studio more than once to get intellisense working again).