Claudio;

You are missing the "spirit" of Dot NET! Productivity from whatever means such as visual objects and property sheets only makes the job easier. We must keep a positive attitude with whatever Microsoft promotes as a development tool. After all, look at all the money they have spent developing and marketing the product.

In the spirit of Dot NET we must concede that a lot of code will be written and it will take several versions before we have a tool that does more of what we want to do rather than jumping through hoops and applying bandages.

Speaking of hoops and bandages, gee whiz – is Dot NET a step forward or what?

The good thing about Dot NET is it will take longer to create a solution for a client. You can therefore charge more! At the same time you will help hone your customer skills by explaining why things are being delivered late. You also get to explain how expected deliverables are not possible due to development tool limitations.

The Microsoft cry: Just wait for the next version! It will solve “all your problems” and then some! Look at Winforms and ADP.NET closely. They have very different functionality. I offer Binding class members as but one example.

I hope to master Dot NET before it masters me! Perhaps in a year or so my thoughts on this subject will have been modified. At least I hope so. :)

Tom

>Hi Kevin,
>
>>As I said before, it gives one a small opportunity to get a little more familiar with the language and framework. It's important for VFP people to realize that .NET is generally more 'code-centric'. Besides, how much time does one really spend add/modifying subclasses in the course of a month anyway?
>
>I agree with you that all developer should get familiar with how to write code in order to get things done, instead of solely relying on visual aids. However, there's a thin line between that and the statement that says "real programmers code in binary". :)
>
>I mean, if I'm creating a specialized textbox class, I'd like to go to a properties sheet and set the properties that controls the appearance of that control, and I'd like to see the results of it immediately. Working with an essentially visual class only in code sounds too backwards to me, IMHO.
>
>Now, answering your question on how much time one spend with subclasses, that depends. Some weeks ago I spent a great deal of time creating specialized visual controls, and I can't tell you how much I hated the fact that I didn't have the visual tools I needed to get the job done quickly. :)