Author's note: the following article was produced from the previous text-based version of the SplitCon documentation and task list (splitcon.txt) last updated on 1/13/2000.  I transformed this text file mechanically into HTML with minimal editing to put it into a more useful, legible form.  There will be no further revisions of splitcon.txt, as this task list has been superseded by the new SplitCon Development Tasks page and its accompanying section in the table of contents, which is handled with a FrontPage include file for the outline of tasks.  The tasks described in these old notes will eventually be assimilated into the new system, but this will be a gradual process.

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\ ****

Copyright © 2000- 2002, SpaceTime Systems