>Do you find that you can customize and extend the framework as we do in our VFP frameworks by creating your own 'subclasses' ( I realize they are not really done that way in .net )

You can do this in SF because you can do this in .NET. You create your subclass by simply deriving from the StrataFrame class you want to inherit from. However, a caveat. In VFP, visually subclassing is straightforward. However, I find that visual subclassing in .NET is far from ideal. There are numerous "visual" classes in SF that are actually created via .NET templates. IMHO, if you want to create your own visual classes that are comprised of numerous visual component classes, they are best handled using a template.

>and not have your modifications over-written if a new version comes out? For example, if you wanted to add some methods to the business object or the maintenance form, could you protect your enhancements from an 'upgrade' of the framework. (

What you refer to here was in fact an issue for .NET applications prior to VS2005. In SF, the business object is created by pointing the Business Object mapper at a datatable. It generates the BO class after this correlation has been made. By using "partial classes", it generates its mappings and the many classes that make up the business object in a partial class. You put your custom BO code in the "BusinessObjectName.cs" file which isn't overwritten by subsequent re-runs of the mapping tool (if you need to regenerate the BO because, say, the mapped table schema has changed). Obviously, the code that is generated for "BusinessObjectName" sub-class derives from the StrataFrame base business object class. So, for every .NET class that is based on partial classes, which, tends to be most things (like native windows forms/ASP.net web forms etc.,) you can simply add any other codefile that complies with your partial class naming convention and irrespective of what the framework or tool does with the code it generates, it will not overwrite your partial class files. However, when you recompile the application, all the partial class codefiles become part of the logical class that they comprise.

I guess to answer your actual question, you can derive (subclass) from any SF framework class and nothing that they do with subsequent changes to their classes will "harm" your subclasses. However, from the VFP perspective, VFP developers are used to creating subclasses of containers containing controls and logic. Whilst this is certainly possible, IMHO, it is not the recommended approach.

>I get the impression that since you pick the objects you add as you create a project you can choose your own versions if you have made mods, but I don't really understand how 'inheritance' works in the .net world yet )

You can add components into your applications that come from the StrataFrame libraries or, add your own that you have created or others that derive from StrataFrame classes. I would just warn again that many of the classes you you will get "out of the box" with StrataFrame like the maintenance form are based on a SF "Standard Form", an "SF Menu", an "SF ToolStrip", an "SF Themed Form Header" and so forth. These sub-components are all classes in their own right. However, when you create an SF Maintenance form, the template "includes and combines" these components at the time the template is run. So, you end up with what appears to be an SF Maintenance form but it is really an aggregation of SF sub-parts. The template code will add these separate components into their parent "containers" at template run-time by adding code into the form's partial "designer" class that creates a private member of the same type as each component being "added" and then constructs each type with appropriate default settings. When VS opens the "new" form, it reads the form's designer class and displays all of the component classes (menus, toolstrips, themed header etc.,) that have been added/referenced in the form's designer.cs codefile.

Whilst you could visually subclass this form, visual inheritance in .NET "sucks" (IMHO) so, you need to think more along the lines of patterns where you combine objects rather than rely on VFP style visual inheritance.

HTH