We have several sections within the training class that talks about this very point.  If you are re-creating much of this logic from one solution to another in .NET, you are not only fighting StrataFrame, but the structure and logic of .NET.  So hopefully we will come to a resolution during the training class that you undertand and are content with on this topic.

We are always open to new ideas and improving the framework.  But there are also many new ways to think in regards to coming from a VFP background.  We too had many of these very same thoughts when we first started in .NET and it took a while before some of the, "lights came o,." which I know will come on faster for each of use as I am a little slow sometimes.  But like Charles said, let's get through the training and you may have many of these questions answered.

I also know that there were many great concepts and ideas in the VFP frameworks that could translate into .NET (many of which we have implemented) while others just fall outside of the basic .NET structure and logic.  Just like anything else, when moving from one platform to another there are going to surely always be different approaches and methods, and this is no different.

I think one of the things we have to keep in mind is that unlike VFP, which for the most part is a one-deep class library out of the box - .NET is in itself a complex framework ( 4,000 classes? ) and a .NET framework begins by building on that.  This is both a source of riches and a PITA for the framework builder.  IT would also seem that in .NET you'd be working with more of the native classes without automatically subclassing them. 

And in the framework, my limited knowledge of .NET causes me to guess that it is not necessary or particularly desireable to subclass the enitre SF class set into a "dev layer" or "i layer" but a more focused approach to extending particular objects either through inheritance or partial class or ... I'm sure there are possibilities I don't yet imagine ... might work better. 

I for one am going to work very hard to have in my head during the training a "feature set" of things I like in my current dev environment that I will look for ways to emulate in SF, but I want to keep my mind as open as possible to understanding the .NET/SF approach without looking for a direct translation from the *implementation* that I'm used to.  I'm sure the VPM guys will do the same. 

The nice thing about having worked with (and benefitted greatly from) a successful framework is that you come to understand the benefits of using the framework as the designers intended and to place a good deal of trust that the designers have also thought about these issues and have made their decisions with a very in-depth knowledge of foundation the framework is built on. 

And in the VFE world I found that really getting into the designers' heads on these issues was an incredible learning tool for understanding the real issues in doing robust apps in that language.

This is gonna be fun

That was a very intelligent and intuitive response, Charles. 

Very accurate...and good choice of acronyms

As you will see, it is using a combination of both.  And in fact, this is something that should be entirely cleared up in the class.

Absolutely!  I really enjoy these classes.  They are a lot of fun!!!  And it is always nice putting faces with forum posts