Barvna shema: Riviera
Trenutno dejavna stran: start » en » Documentation » Microsoft Access development tools » WKL Forms Object Library » WKL Forms Object Library troubleshooting » A control isn't arranged by the layout

A control isn't arranged by the layout

In Form view, a control stays where it was designed while the other areas of a WklDockLayout, or the other side of a WklSplitter, move. Or it moves at first and then drifts away from the arrangement when the window is resized, or an area is missing from PaneNames, FirstAreas, or SecondAreas.

Environment

WKL Forms Object Library 1.16 and later (WklSplitter) and 1.17 and later (WklDockLayout); Access forms, and UserForms in Excel and Word.

Cause

The areas are taken from Panes (from FirstControls and SecondControls for the splitter) or, when those are empty, found by position when the form is first shown in Form view:

  • Dock layout: only visible controls in the layout's own section that lie inside its rectangle count. They're taken off its edges in turn: each time a control along one entire edge, the thinnest first; the largest remaining control fills the rest. A control that doesn't touch any edge of the remaining space, or that lies partly outside the layout, isn't an area.
  • Splitter: only controls in its section that lie alongside the bar within 20 pixels (300 twips) count; a control above or below both areas isn't a neighbor.
  • Anchors set by hand: the splitter calculates from the design positions and needs its areas anchored at the top left; Access stretches a control anchored to the right or bottom without notifying the object model. The dock layout sets its areas' anchors itself based on their position (left, both, or right); anchors you change by hand afterward no longer match the zones.
  • Positions read once: the design is read once each time the form opens. Controls that code moves afterward aren't taken into account until Refresh is called.
  • Hidden by code: a control hidden through Visible keeps its space in the layout; only a collapsed area (PaneCollapsed) gives its space to the others.

Resolution

  1. Check which areas the control uses: Debug.Print Me!Layout1.Object.PaneNames (in Form view or Design view), or the splitter's FirstAreas and SecondAreas in Form view.
  2. Open the designer ([...] in the Custom row). The Areas page (layout) or Splitter page (splitter) shows the areas found and a preview drawn from the form's controls. For the layout, Take over by position writes the areas found to Panes, where you can correct the zones and names.
  3. Name the areas explicitly where the position is ambiguous: in Panes (for example, lstNav=Left; sfMain=Fill) or in FirstControls and SecondControls.
  4. Splitter: set the anchors of the areas on both sides to Top Left. Dock layout: don't set anchors by hand; turn on Set up on applying in the designer and click OK, which sets the anchors of every area based on its position.
  5. After code has moved areas permanently, call Refresh; to remove an area, set PaneCollapsed instead of Visible.
en/wiki/msaccess/comctl/troubleshooting/control-not-arranged-by-the-layout.txt · Zadnja sprememba: uporabnika Wolfgang van der Stille