[AccessD] Form Controls - Class implementation

clsCtlSortSupervisor will find controls for each section and tab PAGE (I said TAB in the comments 
below).

Sorry for the confusion.

John W. Colby
www.ColbyConsulting.com


jwcolby wrote:
> I have sent three emails with the code for the same thing using a pair of classes.  Data and code 
> encapsulation!!!
> 
> IMHO breaking this into classes makes the coding much clearer.  Now you can see that anything in 
> clsCtlsSorted has to do with the controls in a given object (section or tab page).  clsCtlsSorted 
> (almost) doesn't care what the object is that it is storing controls for.  It simply takes an object 
> that has a controls collection and iterates the controls collection, storing the controls found.
> 
> clsCtlSortSupervisor is the supervisor class.  It is responsible for finding sections and tab 
> controls, and instantiating clsCtlsSorted once for each form section and each tab control.  Each 
> instance of clsCtlsSorted is stored in a collection, keyed on the name of the object (section name 
> or tabname.Pagename.
> 
> clsCtlsSorted is responsible for storing the controls in a collection sorted on cstr(TabIndex) of 
> each control. clsCtlsSorted is responsible for discovering whether the controls are directly on the 
> form or in a tab and storing only the correct controls, IOW not store controls which are on a tab in 
> a clsCtlsSorted instance for a section, and not store controls in a section in a clsCtlsSorted 
> instance for a tab.
> 
> Each class has properties and methods for its specific job.  Each has a collection.  Each can return 
> the entire collection.  clsCtlSortSupervisor can return the class instance for any given object by name.
> 
> Each class can be modified to perform other tasks or processes as needed, or can be passed in to 
> other classes to perform processing on the collection of controls that it contains.
> 
> Each class can return a string of the names of the objects stored in its collection.  the following 
> is the string of all controls on a test form (which have a TabIndex property).
> 
> Detail::
>      TabCtl22    Check35 Check37 Check39 Check41 Check43
> TabCtl22.Page23::
>      Check12 Check14 Check16 Check18 Check20 Frame45
> TabCtl22.Page24::
>      Text66
> FormHeader::
>      Combo4  Combo6
> FormFooter::
>      Command0    Command1
> PageHeaderSection::
>      Text8   Text10
> PageFooterSection::
>      Command2    Command3
> 
> 
> 
> John W. Colby
> www.ColbyConsulting.com
> 
> 
> A.D.Tejpal wrote:
>> Run time handling of form controls in the order of tab index.
>> ========================================
>>
>>     Use of a collection as suggested by J.C., appears to be the optimum 
>> approach, provided the point raised by Ken is addressed suitably. A form 
>> having three tab controls each with 4 pages, would need 15 collections as 
>> each form section or tab control page has its own set of tab indices for 
>> controls located therein.
>>
>>     There could be an interesting way to handle this requirement 
>> conveniently by adoption of a single collection where each of its elements 
>> is itself a collection, permitting a generic subroutine to handle unlimited 
>> number of tab control pages apart from the three form sections (detail, 
>> header & footer)
>