Hey Claudio,

>>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.

I don't know, maybe it's just me, but how the heck many properties are there to set/change in a simple control like a TextBox? I don't think that having to set those in code is really a big deal and not being able to see it visually is equally not a big deal, simply because the "look" of a simple control is not gonna change all that much, is it? (keep in mind, I'm only talking about WinForm controls)

~~Bonnie


>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. :)