WklSplitter and WklDockLayout

Two controls that let the user arrange the areas of an Access form at run time, without form code: WklDockLayout lies behind the areas of the detail section and arranges them in zones around a fill area whenever the window changes size; WklSplitter is a single bar between two groups of controls. Both remember each user's arrangement and work on Excel and Word UserForms as well.

• Build an administration form with a dock layout

• How to: Split two areas with a bar
• How to: Choose the areas of a layout
• How to: Set the content of layout areas in the designer
• How to: Build a side bar with cards
• How to: Keep the user's arrangement
• How to: Use the layout controls on UserForms
• How to: Use a layout on a navigation page
• How to: Edit records beside the list (WklDrawer)
• How to: Handle your own shortcuts in an application shell

+- frmAdmin ---------------------------------------------------------------+
| Form header: title, search, commands                                     |
+--------------+-+---------------------------------------------------------+
| tlNav        |#| sfMain                                            [3]   |
|              |#|                                                         |
| [1]          |#|                                                         |
|              |#|                                                         |
|              |#+---------------------------------------------------------+
|              |#|=========================================================| [2]
|              |#| sfInfo                                            [4]   |
+--------------+-+---------------------------------------------------------+
| Form footer: status                                                      |
+--------------------------------------------------------------------------+
 
+- frmCustomer -------------------------------------------+
| lstCustomers       |#| sfOrders                         |
|                    |#|                                  |
| [5]                |#| [6]                              |
+---------------------------------------------------------+

• No form code: the areas are found by position on the form (or named), the layout follows every size of the window by itself, and the user's arrangement comes back the next time the form opens.
• Zones like Windows Forms docking: left, top, right, bottom and a fill area; an earlier area is docked further out. Every docked area keeps its designed width or height and has a minimum size.
• Fills the detail section (FillSection, default): title and commands in the form header, status in the footer, the areas in all room the window has - without drawing the layout exactly or anchoring anything.
• Drag, fold, events: a preview while dragging, one arrangement on release, Esc cancels; a double click folds an area or a side away. BeforeLayoutChange and BeforeSplit can change or cancel a change of the user, AfterLayoutChange, AfterSplit and AfterCollapse report it.
• Remembered per Windows user (AutoSaveLayout): in the local table USysWklLayout of the front end, on UserForms in the registry; Layout gives the arrangement as text for code that keeps it elsewhere; Reset returns to the design.
• Tab groups: several areas share one place under a tab strip - a side bar with the cards “Eigenschaften” and “Memo” - with one card shown at a time; AfterTabChange reports every switch, by the user, by code or on opening, so a card loads its content in one place.
• Keyboard and screen readers: on Access forms F6 and Shift+F6 step between the areas, through a layout on a page subform as part of one cycle; bar and strips are tab stops that the arrow keys resize and Enter folds; UI Automation shows them as sliders with the size as value.
• Designers with a preview drawn from the form's real controls; the dock layout's designer also sets anchors and order on OK, sets what each subform shows and adds new subform areas.

The design is the starting point, the arrangement a few numbers on top. Both controls read the positions of their areas once, when the form first shows, and compute every arrangement from that design: the splitter from one offset (Position) and the folded side, the layout from the zone, size and folded state of each area. Offset 0, or Reset, is the design exactly; repeated drags cannot accumulate rounding errors. Nothing of a run-time arrangement is saved with the form.

The areas are ordinary controls. Subforms, list boxes, WKL controls - the layout and the bar set their positions and hide them while folded, nothing more. Leave their anchors to the designer of the layout: it gives each area the horizontal anchor of its place and keeps the vertical anchor at top (see “Windows wider than 22 inches” below). Access stretches anchored controls without telling the object model, so the layout accounts only for the anchors the designer gives; the areas of a WklSplitter stay anchored top left. A WKL control used as an area keeps its data and selection while it is moved, although Access rebuilds the windows of ActiveX controls after every move.

Which control when. WklSplitter divides two groups of controls along one gap and leaves the rest of the form alone - for example a list and a subform side by side. WklDockLayout owns the detail section: it suits shells and administration forms whose areas should use the whole window. A layout already has a strip after every docked area; do not add splitters between its areas.

Changes by the user and by code. A drag, a double click, a key or a UI Automation call is a user action and raises the Before and After events. The same change by code (PaneSize, Position, Collapsed, Layout) raises none of them, except AfterCollapse; both are remembered for the user.

Design view shows the arrangement. With Set up on applying turned on, OK in the dock layout's designer moves the areas in design view to where the layout puts them: docked areas at their sizes along the edges, a strip's width between them, the fill area in the rest - computed from the designed detail section (with FillSection) or the layout's rectangle. Form view differs only where the window differs from the design: with FillSection the fill area grows with the window, and a user's own arrangement (folded areas, dragged strips) applies in form view only. When the layout finds its areas by position and the arranged form would read differently, the designer writes Panes out first, so the zones stay as designed.

Single forms only. Access shows no continuous forms with subforms or ActiveX controls, so both controls belong to the single form around such areas.

Windows wider than 22 inches. Access refuses Left and Width beyond 31 680 twips (22 inches), but its anchors stretch a control over any width. The layout uses them: the designer gives each area the anchor of its place when it arranges the areas (the fill area and the areas above and below it anchored left and right, an area on the right anchored right, an area on the left anchored left), and the layout fills the whole window with them. Set the anchors in the design, not by code at run time: when the anchor of a subform control changes in form view, Access creates the page anew (record position and everything set at run time are lost). An area without anchor ends at 22 inches. Heights stay limited to 22 inches.

Inside a page (a form in a subform control) Access applies the anchors of the page's controls when the size of the Access window changes, as on any form: in an anchored subform control a text box anchored left and right keeps its right margin from the design, beyond 22 inches as well. A width set by code (sfPage.Width = …) is not applied to the page's Access controls at once: they keep their size until the window changes size the next time and then take the new width. So anchor the subform control instead of widening it by code; a WklDrawer places the controls of its content itself (AnchorContent). A WKL control anchored left and right in a page follows the page at once, also beyond 22 inches and without a dock layout; it keeps its right margin from the design, while its Width still reports the design value. A WklDockLayout on the page and the WKL controls in its areas reach beyond 22 inches as well, with nothing to set besides arranging the areas in the designer. So set the anchors in the page's design, as on any form.

Checking the edges in code. WKL controls offer no window handle (hWnd), and Left and Width of an anchored control keep the values of the design when Access stretches it. In a window wider than the form, Access moves a control anchored right by InsideWidth - Width of the form, and widens a control anchored left and right by the same amount; InsideWidth reports the visible width also beyond 31 680 twips. Its right edge in the window is therefore Left + Width + (InsideWidth - Width), with Width of the form in the brackets. This holds for the areas of a WklDockLayout too: the layout gives an anchored area the rectangle that Access turns into the arranged one by adding its growth, so Left and Width of the area report that smaller rectangle, not the place on screen. To ask where an area is, ask the layout (PaneZone, PaneSize, PaneCollapsed, and GroupPane for the visible card of a group) instead of the control. The inches are logical ones - the window's pixels divided by the Windows scaling, 96 pixels per inch at 100 % - not the screen's diagonal: a maximized window on 2560 pixels at 100 % is 26.7 inches wide, at 125 % 21.3 inches; 1920 pixels at 100 % are 20 inches.

• How to: Install the released package
• How to: Deploy an application with WKL controls to user PCs
• What the per-user registration writes

• A control isn't arranged by the layout
• The layout stays wide after the window shrinks

• API reference: WklDockLayout
• API reference: WklSplitter

None