>>My rule of thumb is to put all the level 1 controls in one library, specially if it's a framework type, ie. to be used accross apps.
>>
>>Within apps, if I have to subclass further, group them by purpose. Separate printing stuff from toolbar stuff from messaging stuff from login stuff from system maintenance etc etc. But I don't claim any originality here - I got that habit from frameworks.
>
>Hi Dragan,
>
>Thanks for the responce. The way you describe it. It's close to the way things are at the moment. But we're in the process of re-thinking thing. And this came up. So if I need only a few textboxes on my form. It won't add the entire library into my exe. This is good to know.

It will add anything that's in your project (the pjx file) and not marked as excluded. The whole class hierarchy, forms, reports etc.

>We have created larger classes that have several of these sub-classed controls in them. These larger classes will handle stuff like printing. And were wondering if we were on the right track. Of starting down a dangerous path.

If I remember well, you're in vfp6sp5, right? In vfp7 and later, recompiling a classlib or any other dbf based thing (dbc, form, report, label) also packs it. In vfp6 it still didn't, and since they're included in the exe, your exe may be suffering from cholesterol (i.e. memo bloat). Each time you edit a method, change a property etc, you're writing to memos, and increase the size of the .vct (.sct etc) file.

So while you're in vfp6, you may want to write a project hook (did these exist in vfp6?) which will just go down each dbf-like object in the project and recompile+pack it, except itself of course - it would error out trying to recompile itself.