The ANCHORS idiom




Drop a control onto a panel and anchor it with a mouse click (or two). Thus setting the layout behavior of the component relative to the panel it sits in.


The current breed of RAD development tools currently does NOT support such a simple layout idiom.




Like most programmers, when working inside a RAD development environment you find there were either no provisions taken by the framework to manage the layout of your components, OR layout managers are provided by the framework that create layouts as extensions to the container they sit within. Layout managers, as the name suggests, present a bewildering set of options that are usually counter-intuitive (focused towards programmer as opposed to the end user) requiring a developers hand in laying out controls that are easy to comprehend, uncultured and has a natural flow and order to their implied behavior that the end user could interpret easily.


Lets take the most popular of all RAD tools, Visual Basic. You have a simple canvas on which to place your controls. Placing buttons, listboxes and other controls on the panel. The controls are fixed in place and size. No provisions were taken by the framework to handle resizing issues. If the programmer wanted to resize controls he would have to override a method, setSize or onResize. For a few controls this is a simple process, however managing multiple views of 100+ controls requiring some controls set their locations while others to change their size can become quite daunting and time consuming.







The most intuitive method would be to place controls on a panel and with a single click ‘anchor’ the components to the panel. The anchors control how the control resizes or relocates itself relative to its parent, the panel.


Imagine a control as a square. On each side of a square there would be a tiny thumbtack (an anchor). That thumbtack/anchor has only two states, either it is anchored into the canvas, or not. Thus each control has four anchors, left, top, right and bottom.


I would place the control on a panel close to the top right corner. To anchor the control to the right hand side of the panel I would ‘anchor’ the right side of the control. So upon resizing the panel from say a width of 100 to a width of 200 the control will remain ‘anchored’ to the right side of the panel.









What if I ‘anchored’ both the left and right nodes of the controls?


The expectation would be that the control stretches, and that is exactly its behavior.










Lets proceed to a more standard layout. Lets build a panel containing a listbox and two buttons.


By ‘anchoring’ the controls as shown below the layout behavior of the controls is easy to guess if we stretch the panel that they sit on top of.




















This is a simple and intuitive idiom to enabling a flexible and simple layout mechanism for any application.




You may have noticed a few properties that this layout exhibits. One of each is the controls can either be moved OR stretched but they cannot be BOTH stretched and moved simultaneously.


The only other (non motion derived) application of stretching and moving a control simultaneously is to ‘zoom’ into a control. ‘Zooming’ implies zooming the text, graphics and other objects that reside within the control in the exact same scale. A layout manager is in charge of laying out controls in relation to the panel that they reside on. It is a completely different process to scale that panel and all its controls. It is much more then merely setting the controls location and size. Thus is NOT a valid requirement that a layout schema needs to handle. 



SEE ALSO: include and loadgui