Additional features for Table Layout in V13 SP1

Date: 1 July 2013
Product/Release: Visual LANSA - V13 SP1
Abstract: New in V13 SP1 - Additional features for Table Layout and specific support in the IDE that significantly simplifies form and reusable part design
Submitted By: LANSA Technical Support

Version 13 introduced Table Layout which represents a new approach to control positioning and resizing. v13 Sp1 builds on this base, providing additional features for Table Layout and specific support in the IDE that not only significantly simplifies form and reusable part design, but effectively supersedes all other layout types for all but a few very highly specialized cases.

Typical Layout Problems

The form below is a relatively common type of dialog design. The fields on the right show a more detailed view of the item selected in the list on the left. Toolbar buttons provide commands to modify the selected items in some way, and the buttons in the footer allow for changes to be committed or cancelled.

Example of common dialog design form
Figure 1

The form has an attachment layout. The toolbar is attached to the top and the footer area is attached to the bottom. The body panel is attached to the center. The top and bottom areas will adjust their width as the form resizes and the center will resize to occupy the remaining space.

The body panel has a vertical split layout so that the list can be resized. As a result, a further Fields panel is required to subdivide the body. The fields themselves need no layout as they are static, and similarly the toolbar does not need to layout the buttons as they too have no need to move. However, the buttons on the footer must move left and right as the form changes size, so this requires a flow layout.

Whilst this is not the most complex of layouts, we can already see how layers of panels need to be created to get the desired result. This is necessary because the behaviour of each of the Layout Managers is very specific, and as any given composite control can only have one Layout Manager assigned, it is impossible to mix and match. Thus, we create areas of the screen by adding panels and then make each panel lay out its child controls as required.

For the most part, this approach to laying out a screen works quite well, but it begins to run into issues as screen designs become more complex. In particular, if we need to have two controls occupy some or all, of the same region of the screen, or we need different layout behaviours in the same screen region, we need to add yet more layers of panels and subdivide the UI further to get the result we want. Not only is this complex to create in the first place, but any change to the user interface at a later date is inherently complicated.

A further and far more subtle issue that this use of panels presents can be found when using the new User Designed Controls. These create many instances of design reusable parts. Panels support scrolling and are quite complex things in themselves, so while creating one panel on a form is of no real concern, creating several thousand in a UDC most certainly is.

How Does Table Layout Work?

Table Layout divides the space in to horizontal and vertical divisions i.e. rows, columns and dividers. These can be a fixed pixel width/height or a proportion of the remaining space once all fixed divisions have been evaluated. Unlike other Layouts, Table does not have predefined behaviour for the controls that it manages: its purpose is simply to define a grid or set of coordinates by which controls can be positioned.

Instead, each control has a Layout Item that determines its behaviour. This is created when the control is dropped on the designer, or simply by starting to specify layout features for the control. Each item has a row and column, a row span and a column span. This defines an imaginary rectangle in which the control is positioned. The Sizing, Alignment, MarginXxx, and Flow properties then locate the control within the rectangle.

The Alignment property locates the control in one of 9 possible positions, TopLeft, Center, BottomRight etc. As Table Layout allows controls to occupy the same space, multiple controls with the same alignment will be shown on top of one another unless a Flow is specified.

Sizing determines how big the control is. Controls can fit to width, height, both or simply appear as designed. If a row or column resizes, the control will resize too.

Flow can be used to force controls to appear in sequence. This overrides Table’s natural behaviour of putting controls in the same space. Instead, it forces them to go to the Left, Right, Top or Bottom of controls in the same cell, but only those with the same Alignment and Flow. This allows different groups of controls with different flows to occupy the same cell. It is also quite possible that a control will appear outside of its specified row and column due to Flow behaviour, but it will still size and align as though it was in the cell.

Each of these properties is independent of the other, and each control is independent of the other controls, flow notwithstanding. This independence is perhaps the most important concept with Table Layout. Controls lay out and resize independently of each other. This means that should you change the row and column span of a control to make it wider, the remaining controls will not be affected.

Adding a Table Layout

Adding a Table Layout couldn’t be easier. The New Layout button on the ribbon puts Table front and centre. Move the mouse over the grid displayed and choose the size required. Vertical and horizontal Dividers can be then be added afterwards, and all can be maintained on the ribbon. Controls can then be dropped onto the designer as normal.

Adding a table using the new Table Layout Button
Figure 2

Designing a Layout

Table layouts and the IDE have been designed to greatly simplify the design process. There is no longer a need to divide the UI in to areas with panels as the Table does that already, and each control when added defines its own layout behaviour. This means that drag and drop from the Controls View, Repository Browser, or around the design can be a lot more effective.

For example, the Designer makes a couple of assumptions. The first is that composite controls like panel, lists, and user designed controls are more likely to resize as the form resizes, while other controls such as labels, spin edits, check boxes and other user input devices are more likely to remain the same size.

The second is that some controls naturally need to spread out neatly. For example, a toolbar will show several buttons. When a toolbar button is added to the layout, it will default to Flow(Left) so that the buttons line up correctly. Similarly, when fields are dropped on a Table they are aligned TopLeft with Flow(Down), ensuring that they stack neatly down the page. As normal, the DisplayPosition property determines the order in which the controls are placed.

It also means that when controls are moved from one cell to another, they take their behaviour with them and simply apply it to the bounds defined by the new cell. If that happens to coincide with other controls, they won’t be affected. This is a common issue with older layouts, in particular Attachment which often causes other controls to resize inadvertently.

Using the Designer

The defaults applied to certain controls are just that, defaults. Once added to the design all of the properties can be modified as required. However, unlike the older layout managers, Table Layout has been fully integrated in to the ribbon and the designer. This means that Layout features can be accessed directly from the ribbon without needing to go to a separate dialog or view. Further to this, the designer allows for simple resizing and repositioning of controls, as well as resizing of divisions and the addition of dividers.

Example layout in the designer
Figure 3

In figure 3, the toolbar buttons have actually been parented to the form and are aligned CenterLeft with a flow of left. This isn’t strictly necessary, but the table is there so we might as well let it organize the controls for us. The Panel has been added afterwards and has a Sizing of FitBoth and a column span of 3 (the divider counts as a column), set by simply dragging the panel wider. It has a DisplayPosition greater than the toolbar buttons, so it goes behind them gives the appearance of being their parent. The panel is really only necessary so that we can apply a different style to that area so that it looks like a toolbar.

A column divider has also been added. Dividers are automatically added between the first two available divisions, and by default they occupy the space available and will always be on top. However, they can be adjusted to start and end on whichever division is required. Here the divider starts on row 2 so that it doesn’t overlap the toolbar.

Listview has just been dropped on the design at Row2 Column 1
Figure 4

In figure 4, the Listview has just been dropped on the design at Row2 Column 1. By default its Sizing has been set to FitBoth and it has therefore resized to fill the cell. However, by dragging the bottom corner over the row below, the layout of the list will be updated and it will immediately occupy rows 2 and 3. Similarly, if the Listview is dragged from one cell to another, the Listview’s row and column will be updated and it will move to the new location.

The result of dropping several fields on the form
Figure 5

Figure 5 shows the result of dropping several fields on the form, in this case at column 3 row 2. The designer sets their Alignment to TopLeft and Flow(Down) and they immediately position themselves correctly in the cell on which they were dropped. As they all remain selected after a drop, it is a simple task to separate the fields by changing the margins, and the form is almost complete.

In the initial form (figure 1) these fields had no layout because it wasn’t required and going to the effort of creating the layout would have been a waste. But with Table, the layout is already there so we get to reap the benefit of being able to use it to organize the fields.

Adding buttons
Figure 6

Buttons automatically flow left when added and have an Alignment of TopLeft. In this case they were dropped on row 3 column 3. Their alignment was changed to bottom right, flow to left, and margins were added to move them away from the edge.


Consider now what would be required to add a help toolbar button to the right of the toolbar if we were still using the old layouts. We’d need to give the toolbar an attachment layout, attach a panel to the right and then add the button. With Table we simply add the button, positioning it at row 1 column 2 and set its alignment as CenterRight.

Organizing the UI with a Table Layout is far quicker, far simpler, far less intrusive, and far less error prone, and not only that, it allows us to create components that have a much lighter footprint.

Table layout is available for DirectX and Win32.