|--< intro >--< api >--< overview >--< sourcetool >-| 
 
 
     At this time this package is considered beta yet will be considerably improved to provide developers with the features that they are interested in. With any luck, the FrameManager source tools and examples will be at the upcoming developer conference.
 
WEdgeManager 

  
Overview 
In general this class should be used in conjunction with something which calls the Layout() method. If your application has a static layout this may be useful as a stand-alone class. Presently I incorporate it into WLayoutWindow for experimenting with real time layout management. (WLayoutWindow simply calls Layout() everytime a window is shown, activated or resized.) 

This class is extremely dependent on the use of WFrame objects. These are used to describe the positioning for any BView. Multiple BViews may use the same WFrame. This allows for tab view classes  hiding/showing scenerios to be easier and increases efficiency. 

Other layout managers can sit on top of this class for flow layout, tk packing, java'ish awt layouts, etc. These types of proxy classes will consist of an instance of a WEdgeManager. They will take sets of views and simpler description parameters and in turn describe this to the WEdgeManager. Unless the developer requests more modifications through the proxy class, the WEdgeManager will have complete layout control. Of course, keep in mind that what that really means is that your components will be arranged by the WEdgeManager when requested. 
 

  
Public Member Functions 
 
WEdgeManager(); 
    There are no parameters; all it's behavior is defined through the addition of View-Frame associations.

 void Manage(BView *view, WFrame *frame); 
    This will register a view and a given frame with the manager. It assumes that a frame has been defined with the appropriate resizing and positioning behaviour.


void  StopManaging(const WFrame *frame); 
    This will remove all entries of view which were managed with the given frame.


void  StopManaging(const BView *view); 
    This will remove all management of a given view. Other views which were associated to given view still hold their reference. To totally disassociate a view throughout the manager use Remove(). The sole purpose is to remove the frame entry associated to the given view.

 void  Remove(const BView *view); 
    A much more thorough function; this will remove all entries which refer to the given view. The end result is that views which were positioning themselves in relation to the given view will no longer do so. Obviously, this is useful if you plan on removing aligned views.


 void  Layout(const BRect& frame); 
    This function should be called to position the managed views. The frame is the parent frame for the managed objects. Look at the implementation of the example code within the WFrameWindow class for the most common example of the use of this member.
 
 
 
 
 
WFrame 

  
Overview 
The basic premise is this - a container is generally divided into regions where components are added. These regions may shift around and be reused by lots of sets of components. As you resize a window some regions may proportionally adjust, others remain in a specific spot. I call these regions WFrames. 

This is important to remember: 
 
A WFrame doesn't actually exist on the screen. It has no literal coordinate values. It can only resolve an edge value when combined with a BView. Building edge dependencies  for BViews must be described in terms of other BViews, not WFrames. In turn those BViews may use a WFrame to associate its edges to itself, siblings or its parent. 

The enumerations defined with the header are particularly important: 

    enum { 
     USE_LITERAL = 0, 
     USE_PERCENT, 
      
     USE_DELTA, 
     USE_NONE, 
      
     USE_PARENT, 
     USE_SIBLING, 
      
     EDGE_LEFT, 
     EDGE_TOP, 
     EDGE_RIGHT, 
     EDGE_BOTTOM, 
     EDGE_OPPOSITE, 
     EDGE_ADJACENT 
    };
These are used to explain what edge you wuld like to arrange, with regards to what component (sibling view or parent container) and with what positioning mode. Refer to the overview and the sample uses in the Set() method to get a better feel for how these enumerations are used. 
 
  
Public Member Functions 
 
WFrame(BView* view); 
    There are no parameters; all it's behavior is defined through the Set() functions.

void Set(ulong whichEdge, 
         ulong whichRelation, 
         float howMuch); 

void Set(ulong whichEdge, 
         ulong whichRelation, 
         ulong whichViewRelation, 
         float howMuch); 

void Set(ulong whichEdge, 
         ulong whichRelation, 
         BView *whichView, 
         ulong whichViewRelation, 
         float howMuch); 
 

    These functions all you to define all the edge arrangements which are documented in the overview of the package. Here are source examples to help you implement different relationships among views: 
     
       
       
      Set(EDGE_LEFT, USE_NONE) 
      Set(EDGE_LEFT, USE_DELTA, 10);
      Set(EDGE_LEFT, USE_PARENT, USE_LITERAL, 10);
      Set(EDGE_LEFT, USE_PARENT, USE_PERCENTAGE, 50);
      Set(EDGE_LEFT, USE_SIBLING, aView, EDGE_ADJACENT, 0);
      Set(EDGE_LEFT, USE_SIBLING, aView, EDGE_ADJACENT, 5);
      Set(EDGE_LEFT, USE_SIBLING, aView, EDGE_OPPOSITE, 0);
      Set(EDGE_LEFT, USE_SIBLING, aView, EDGE_OPPOSITE, 5);
      Set(EDGE_LEFT, USE_SIBLING, aView, USE_PERCENTAGE, 50);