Charles,



Drew had a terrific utility in Maxframe that allowed you to assign the parent class of any object on a form or class at any time. I got into the habit of just tossing labels, text boxes, etc on a new form and then changing them all to the project specific versions after they were all there. Made things really quick. (spoiled me also!)



This brings up a question that may be in the docs but I have just started, so bear with me. When building a new project in VFP I would always have "bills-company" class libraries that were subclasses of the Maxframe class libraries. Then I would subclass the "bills-company" classes for each project. I found this gave the the most flexibility but never seemed to impact performance negatively. Does this sound like a good plan for SF?



Bill

Hi Ivan,



Thanks! Never used Codemine but I did a couple projects with the original version (from the book) of CodeBook! The client (back in Pittsburgh) is still using the application!



Bill

Sounds like Maxframe used prg classes. Cool. The .NET version should make a lot of sense then.



Yeah, in VFE we had a layer that was subclassed from the VFE framework that we could customize and count on it not breaking if F1 put out a new release, then we would subclass from that for the app.



A little different here, partly because it is easy to go back and retrofit. If you have developed stuff that actually extends the framework, by all means use it from the get-go in the project, but otherwise just use the SF classes, knowing when you have subclassed them for some reason you can implement the subclasses pretty painlessly.



I think developing a base businessobject - even if at first it has nothing fancy - is fine as that is probably the first place you'll be putting in generic goodies. I also have a seperate project, which for development purposes I keep in the same solution - for subclassed UI controls that I use in all my apps. And in your base assembly/project (see below) you will start building a library of routines you may use throughout the app ( and perhaps later will want to abstract to an assembly you reference in all your apps)





I think a big thing at the beginning is looking closely at the Strataframe sample. Unlike the getting started tutorial, it is more "real world" in showing how a number of projects/assemblies will make up a finished app. That is probably the first big mental paradigm shift to get through in moving to SF/.NET. Figuring out how to reference the other projects within the app is a little strange at first, and then you have to get used to needing to rebuild sometimes before seeing changes in one assembly reflected in another.



You will very much like the convenience SF builds into creating parent/child stuff etc. Les has a good turtorial on that on his website. First gotcha to be aware of is setting the relationship between the parent/child BOs in the solution explorer before going to the child instance dropped on the form to set the parent business object. The trick is to double-click the child in the solution explorer first, then go to property sheet to see the parent relationship property. That is one example of where you may have to build your BO project before you will see the parent in the dropdown when picking the parent BO in the instance.



Some of this stuff looks less complicated when you have everything in one big project, but you'll find that the benefits of have a main project, Base, BusinessObjects, UI, Reporting and maybe some others is worth the trouble.



I'm sure others here will chime in with some good tips for getting off on the right foot.