Hi John!
If in your experimentation you develop a framework for the .net world, count me in! I'd love to see it. My dream would be to be able to use a product similar to VFE with VB or C#! Then I could easily switch between the two in order to use the most appropriate tool for the job.
Tracy

>Hi Mark..
>
>An interesting thread. I would like to throw a few thoughts into the mix...
>
>
>As far as the CLR is concerned, the focus should be on the framework - not a particular langauge. A CLR langauge implements the framework. Whether you are using VB or C# - how you work with windows forms and components is exactly the same. The only difference are the syntactical differences between the two langauges (; in C# and Dim in VB, etc..)
>
>Some say that each language lacks a distinctive character. That may be true. IMO, the character is the framework - not a particular language. Being language centric has always been a sore spot with me. IMO, being tool/solution centric is a better approach. Then again, language-centricity makes for better languages. In sum, I can see both sides.
>
>In case you did not know, Alan Griver (Formerly of Flash Creative Management and GoAmerica and still an acknowledged VFP Guru) is going to be the VB .NET Language Evangelist for MS. I don't know what his exact title will be. However, I do know this...if MS is hiring people like YAG to make the langauges as good as they can be, coupled with the serious dollars that MS is investing in .NET - the entire initiave will succeed.
>
>As far as frameworks are concerned, I definitely think you will see them. Given that .NET itself is an OO framework, it is a valid conclusion to make that people will subclass as needed to build application components that suit specific needs. To compare this sitation to the lack of VB frameworks in the past is like comparing apples and oranges. First, .NET is fully OO - and that makes a big difference. Second, there is full language framework independence in .NET. Not only will you be able to build frameworks, they can be used and subclassed with any .NET langauge. Further, your components - at least the middle tier ones - can be used in COM-based apps via COM/Interop. IMO, I don't think it is too early. Rather, I think nobody has undertaken the task - or at the very least, nobody *you know of* has undertaken the task.
>
>Anybody who says .NET - and specifically VS .NET is perfect is looking at the world through rose-colored glasses. However, as somebody who has actually worked with - and soon to be published in the product (and I emphasize this because prior to rendering strong comments, I think people should take some time to learn about and use the product) - I can tell you that VS .NET is the real deal. Will it be widely used the day it is released? No. But, in 2 years, I think you will see a signficant amount of .NET development.
>
>To dive head-first at the expense of everything is a mistake. To completely ignore the product is a mistake as well. This product probably gets more funding in a week than some products get in an entire year. Bill Gates at the MVP summit had a great quote "I can predict the future because I have the benefit of a $5 Billion R&D team that can make my predictions come true..." I paraphrased, but that is the gist.
>
>One last point...about the VB developers you work with that get snotty. Keep in mind that it is NEVER the fiddle - it is ALWAYS the fiddler. Case and point - I wrote the first cut of Dataclas/COM. It is 100% VB and it is OO. It does not support inheritance - but then again, it does not have to. Rather, it uses aggregation. At the same time, I also developed a little VB application framework that ships with the product I believe. Again, it is not like a VFP framework - but it is a framework nonetheless. The point of course is that if you task certain developers with a task - while one tool can make certain tasks easier - in the end, it all evens out. For example, in VB, while there is no inheritance, working with ADO is a lot easier. And, if you understand the tool, you can be productive. The point is that whether a VB developer is productive or not has almost nothing to do with the tool. Rather, it has to do with the skills of the developer and how well he understand the VB tool.
>
>In my own .NET work, I have already toyed with the idea of creating form templates with command buttons that make quick work of creating data-entry forms. There is still more work to do - but it is a start. Most definitely - it is not too early to look at and work with the tool. And that includes framework experimentation....