The idea behind the splitter control in the bkgui dll
is as follows:

a) the splitter bar is actually a stripe, more like a gap or a "lane-marking"
   where the mouse interact with the client area of a parent object (the way)
   dividing  the object in 2 parts (lanes).
   In this implementation, a splitter bar is [b]not[/b] a child window,
   but a gap between two things; it is a part of the client area 
   of a parent window. It is more like an "absence" than a "presence" of something. 
   This is not philosophic, because on the contrary, it allows the "avoid-to-draw"
   instead of the "too-much-drawing" with the well-known and 
   wide consequence of a hard-boring-flickering.

b) Child controls must be redrawn from the parent window (if
   not subclassed) or redraw itself by what i call 
   "cascade splitting". Because of the fact that they are more often 
   subclassed controls containing more other splitbars that divide 
   their own area to adapt more other little children windows.

c) All user programming results very simple and flexible:
   manage WM_PAINT,WM_MOUSEMOVE,WM_LBUTTONUP,WM_LBUTTONDOWN,WM_SIZE,
   with almost the same code (100/400 bytes totally) even for multisplitting
   like in fasmlab. It seems complex, but i can assure 100% this is the 
   simplest implementation i know for splitterbars, if you require it flexible
   for [b]multisplitting[/b] (on the same area) or [b]cascade splitting[/b]
   (if you have child panels that act as client area wherein  children control must be split).
   User can split normal (as in fasmlab) or "live", it is to say, decreasing
   and growing child windows on place directly.

d) Actually, the splitter in the bkgui.dll makes only calculations
   to RECTs,it is to say it maps the rectangles, left/right (lx/rx)
   or up/down of a parent client area that it divides. 
   Also, it doesent draw anything, but its lane-marking,its gap.
   This is a very important issue to consider.
   This is a flexibility issue for future implementations.

   Infact, with few changes in the main code (actually, 1kb compiled),
   i will implement in a near future:

   1) the custom line drawing, user choose how the splitter will be drawn.
      ( this is a partially implemented feature; i am testing it
      to obtain an ollydbg-like taste splitting in my new own hexadecimal  
      viewer/editor, that will be re-built again in fasmlab as soon as 
      i am ready with that)

   2) will allow dockability of the children windows

   3) the schemataS to a layout, to handle simply messages and rect maps,
      for example:
      - T schemata (1 horz splitter,1 vert splitter)
      - I schamata (1 simple vert splitter)
      - H schemata (2 vert splitter, 1 horz splitter,like in fasmlab)
      - L schemata = T inverted
      - E schemata (3 horz splitter)
      - U , W etcetera 

   4) keyboard splitting (not yet implemented,but simple to do)
    
 ok,the old bkgui.dll exported these functions, self explanatory
             
    mapHsplt   ; gives 2 Horz rects from a 1 client area rect,dividing it
       mapVsplt   ; gives 2 Vert rects from a 1 client area rect,dividing it

    split.redraw
        split.release
       split.split
         split.capture
       split.create
        split.getpos
        split.destroy