I'd keep non-UI and UI classes in different VCXes. Also, keep form classes separate from other UI elements.

>Hi Cindy, Craig, Larry and Alex,
>
>Thinking about this subject makes me conscious how A/R I am about nomenclature and classifications. I am otherwise pretty disorganized. However, in order to get off on the right foot in this matter I'd like you opinion.
>
>What do you think of this organization for class libraries/classes:
>
>1) _base.vcx. Contains first level classes. (_txt, _frm, _cmd, etc)
>
>2) _framework.vcx. Contains classes that remain the same from project to project: for example, _app, _frmDataEntry, _report, _ds (data services), _biz (the base business object class).
>
>3) _aframework.vcx. Contains equivalent classes to those in _framework.vcx, but subclassed for this application. (_aapp,_afrmDataEntry, _areport, _ads, _abiz)
>
>4) _abizlib.vcx Contains business objects for this app. e.g. _bizEmployee, _bizTransaction, etc.
>
>Values that need to be easily accesible throughout app would be oApp properties.
>
>Thank you.
>
>Alex
>
>>Alejandro,
>>
>>One thing no one else has mentioned is the global variables. First, any variable initialized in the main program, though private by default, will function as a global variable because it will be visible to the whole application which runs from there on down.
>>
>>Many people use an application object which holds these variables as its properties.
>>
>>
>>>Lastly, I use global variables to hold some frequently used values that I do not wish to fish repeatedly from the parameter table.