Preliminary Notes About the Generic SplitCon Application
	By M. Asherman, 1/13/2000

	Intro:

The SplitCon application consists of a demo form and a general purpose class library for adding "splitters" to any VFP application.  This work was loosely adapted from Doug Hennig's sample splitter class, which is described in his article "Splitting Up is Hard to Do" reprinted from the July '99 issue of FoxTalk, which is included in Microsoft's MSDN Library CD of 10/99.  I made a number of departures from Doug Hennig's approach in order to create a simpler, more modular facility, avoiding all dependencies on either the Stonefield framework or VFP's FFC classes.  Also, my SplitCon adds the generalizations of supporting a two-dimensionally split container, i.e. with multiple rows and columns of splitters, and it supports nested split subcontainers, if desired.

	Currently available documentation:

- run splitcon() to see the tabbed split container demo form
- brief descriptions have been attached to all files in splitcon.pjx
- all programs are liberally commented
- the current implementation of the SplitCon facility is totally self-contained
	I.e. it doesn't depend on any other mdacomm utilities.
	
	Related outstanding issues and tasks (* indicates it can wait):

- restrict drag to prevent crossing over neighboring splitter bars
	Only affects cases with more than 2 subcontainers (e.g. see 3X4 example).  Punting this issue initially, because the immediate application to Saver's Swich To... dialog only requires a 2X1 split container. 
*- refinement to dragging to allow for finite width of splitter bars
	Avoid slight jumpiness caused by failure to preserve the initial offset of the mouse within the bar.  This offset should be maintained as the splitter is dragged.  Issue becomes less important as the splitter is narrowed.
*- dynamic splitcon features
*- optional parameter for whether to scale splitter spacings on resizing
*- consider supporting optional init args that would specify dimensions
	I.e. auto-create subcontainers and splitters rather than have to define separate classes for each case.  We could assume even initial spacing of splitters by default.
*- maybe should highlight splitter bar during drag
	Maybe not necessary, given sufficient other feedback.

	General guidelines and conventions:

@- watch out for proper release of internal object refs
	No sign of trouble so far, but always watch for this when storing internal object refs, as is done in SplitContainer.
@- maintain clean copies of selected files in shared mdacomm directory
	For SplitCon, this includes SplitCon.txt/vcx/vct.
@- rebuild any dependent apps after changes to shared SplitCon stuff
	E.g. Saver's Switch To... dialog will be revised to use a SplitContainer class.
@- maintain thorough error and escape-handling provisions
@- avoid unnecessary direct cross-app dependencies by making use of mdacomm
@- all apps should avoid potential name conflicts in case moved into mdacomm
	E.g. avoid file names like "notes.txt" in favor of "<appname>.txt".
@- add comments in history of each app as to when last uploaded to BT server

	Change history:
	
991203 **** UPLOADED CHANGES TO BT SERVER'S D:\REDP\APPL\SPLITCON\ & ...MDACOMM\ ****