Autosize / Layout/zh TW: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		# 概述
2	2
3	3		LCL 會自動修改 controls 的大小和位置，所以它會根據字體，主題，文字和其他內容來自動適應。如果你想讓你的程式在多個平台上執行，或者程式裡的 captions 有多個語言。那麼，你的 controls 需要正確地適應本地環境. LCL 不僅允許你用快速的第一設計模式（用滑鼠在 form 上移動 controls），也允許你之後再改動一些主要的屬性來使得 controls 自動適應後來的內容變動。
4	4
5	5		- Fixed design: 當在 designer 裡放置好 control 後，它就預設地啟用. Control 的位置相對它的父組件是固定的. Control 的大小和位置(Left, Top)可以被程式員改變。你可以自由地用滑鼠移動 control 或改變其大小。
6	6		- Aligned: 對齊的 controls 會根據設定填充父組件的頂部，底部，左邊，右邊的剩餘空間或者整個剩餘空間。
7	7		- Anchored: 你可以在 control 的邊上(left, top, right, bottom)拋錨，錨住父組件或者另一個 control. 一旦錨住後, LCL 就會使得拋錨的那個邊和被錨住的組件的距離固定。
8	8		- Layout: controls 可以自動地依據行列對齊(例如 TRadioGroup)
9	9		- Custom via OnResize: 自己處理 OnResize, OnChangeBounds 事件，你就可以自己安排 controls 了。
10	10		- Custom controls: 自己寫 controls, 那麼你就可以按你需要覆寫幾乎所有 LCL 行為了。
11	11
12	12		## 優先級規則
13	13
14	14		1. Constraints
15	15		2. Align
16	16		3. Anchors
17	17		4. ChildSizing.Layout
18	18		5. AutoSize
19	19		6. OnResize, OnChangeBounds - 要注意的是，如果你設定的 bounds 和上述規則有衝突，那麼程式會進入無窮迴圈。
20	20
21	21		## 常用屬性
22	22
23	23		一些用來配置 autosizeing 的重要屬性：
24	24
25	25		- Left, Top, Width, Height
26	26		- AutoSize: autosize 另 LCL 自動地更改 control 的寬和高。
27	27		- Anchors: 創建一個錨。例如，將一個 ComboBox 錨在一個 Label 的右邊。
28	28		- Align
29	29		- Constraints: 設定寬和高的最小值和最大值。
30	30		- BorderSpacing: 設定被錨住的 control 之間的空間。
31	31		- ChildSizing: 設定子 control 的 layout 和空間。
32	32
33	33		上述法則的內部原理在此有描述： [[LCL AutoSizing]].
34	34
35	35		# Fixed design
36	36
37	37		這是預設設定. Anchors 屬性會被設定成 \[akLeft, akTop\], 也就是說, LCL 不會改變 Left, Top. 如果 AutoSize 為 false, 那麼 Width 和 Height 也會保持不便。如果 AutoSize 為 true, 那麼 Width 和 Height 會改動以適用內容。例如, TLabel.AutoSize 預設是 true, 因此，改變 Caption 就會重設 label 的大小. TButton.AutoSize 預設為 false, 所以改變 Caption 不會重設按鈕的大小。當你將 Button.AutoSize 設成 true 後，這個按鈕會在每次 Caption, 字體，主題改變後縮小或增大。要注意的是，這種改變不總是立即進行的。例如，在 FormCreate 時，所有 autosizing 動作會懸掛。你可以在任何時候改變 Left, Top, Width, Height 屬性。
38	38
39	39		# AutoSize
40	40
41	41		`AutoSize` 這個布林屬性出現在許多類中；它允許 control 自動進行大小的調整以適應它包含的文本或圖形，也允許最有效地使用可用的空間。這是創建跨平台窗體的一個非常重要的機制。
42	42
43	43		通常, AutoSize=true 後，會為可見 control:
44	44
45	45		- 如果可能，它改變 control 的大小到 preferred size. 例如，一個 TButton 的寬度和高度被改變大小以適應它的 caption, 而對於 TEdit, 只改變高度. TEdit 的寬度不會自動改變大小。你可以手工改變它。可參考下 GetPreferredSize.
46	46		- 它同時移動所有固定位置的子 control。最左邊的子 control 會移到 Left=0 (依賴於 BoarderSpacing), 最上邊的子 control 會移到 Top=0.
47	47
48	48		## Difference to Delphi
49	49
50	50		Delphi 的 AutoSize 僅在特定的屬性改變時作用。例如，當 TLabel 的 Font 被改變時. LCL 的 AutoSize 總是有效的。例如，在 Delphi 裡，一個 AutoSize=true 的 Label 仍然可以設置大小(可能造成部分或全部 Caption 無法顯示), 這在 LCL 中是不會出現的，因為 AutoSize 總是起作用。另外，隱藏的 controls 不會被改變大小。
51	51
52	52		## AutoSize and resizing the control
53	53
54	54		當 AutoSize=false 按鈕就會呈現固定的大小。
55	55
56		-	~~<figure>~~
57		-	~~<img src="Autosize1.png" title="Autosize1.png" />~~
58		-	~~<figcaption>Autosize1.png</figcaption>~~
59		-	~~</figure>~~
	56	+	![](/wiki-images/1/1f/Autosize1.png)
60	57
61	58		當對 button 設置 AutoSize=true, 那麼這些 buttons 就會被增大或縮小以適應文字或主題框架。
62	59
63		-	~~<figure>~~
64		-	~~<img src="Autosize_on.png" title="Autosize_on.png" />~~
65		-	~~<figcaption>Autosize_on.png</figcaption>~~
66		-	~~</figure>~~
	60	+	![](/wiki-images/7/75/Autosize_on.png)
67	61
68	62		如上圖的 OK 按鈕所示, AutoSize 並不會將按鈕縮小到儘可能小。它使用GetPreferredSize 來獲取建議大小，這個函數又會調用 CalculatePreferredSize. 預設的 TWinControl 實作會查詢 widgetset, 它可能設定了建議的 width 和 height. 每個 control 都能覆寫 CalculatePreferredSize. 例如， TImage 就覆寫它並返回圖片的大小。如果沒有沒有建議的 width(或 height), 那麼就返回 0, LCL 會保持 width(height), 除非 ControlStyle 標記 csAutoSize0x0 被設置(這個標記當前只被 TPanel 使用).
69	63
70	64		TWinControl 計算它所有的 controls 的大小，然後利用這個值來計算它自己的建議大小。
71	65
72	66		當一個 control 的左錨和右錨都錨到其他對象，那麼它的寬度就是固定的(動態的固定，依錨住的對象的位置變動而改變)。例如，當 Align=alTop(Align 屬性可看作一個快速設置錨的屬性，會覆蓋錨的設置), 這個 control 就的左錨就錨住它的父對象的到左邊界，右錨就錨住它的父對象的右邊界。之後它的寬度就隨父對象而改變了。如果 Parent.AutoSize 是 true 的話，那麼 Parent 將會實用這個 control 的建議寬度來計算它自己的建議寬度，參閱 [[Autosize / Layout\|Align and AutoSize]]. 如果沒有可用的建議寬度，那麼就使用最後設置的邊界(BaseBounds 或者 ReadBounds). 如果邊界為設置，那麼就調用 GetControlClassDefaultSize 方法。對於 Height 也是同樣的機制。
73	67
74	68		Constraints(約束)總是起作用，且優先級更高。
75	69
76	70		## AutoSize and moving child controls
77	71
78	72		When AutoSize=false you can place and move controls freely:
79	73
80		-	~~<figure>~~
81		-	~~<img src="Autosize_on.png" title="Autosize_on.png" />~~
82		-	~~<figcaption>Autosize_on.png</figcaption>~~
83		-	~~</figure>~~
	74	+	![](/wiki-images/7/75/Autosize_on.png)
84	75
85	76		When AutoSize=true child controls with fixed positions are moved to fit.
86	77
87		-	~~<figure>~~
88		-	~~<img src="Autosize_panel_on.png" title="Autosize_panel_on.png" />~~
89		-	~~<figcaption>Autosize_panel_on.png</figcaption>~~
90		-	~~</figure>~~
	78	+	![](/wiki-images/d/d9/Autosize_panel_on.png)
91	79
92	80		Both buttons on the panel were moved by the same amount to top and left, so that there is no space left to the left and top. If the buttons would have BorderSpacing\>0 or the Panel.ChildSizing.LeftRightSpacing\>0 the buttons would be moved so that the defined space is used.
93	81
94	82		Only child controls with the following values are moved:
95	83
96	84		- Anchors=\[akLeft,akRight\]
97	85		- AnchorSide\[akLeft\].Control=nil
98	86		- AnchorSide\[akTop\].Control=nil
99	87		- Align=alNone
100	88
101	89		The moving of the child controls depend on the propert [[Autosize / Layout\|ChildSizing.Layout]]. The layout is applied in the method TWinControl.AlignControls which can be overridden. For example TToolBar overrides that and defines a flow layout where controls that do not fit are put into subsequent lines.
102	90
103	91		Controls can disable the moving of child controls by setting the ControlStyle flag csAutoSizeKeepChildLeft and csAutoSizeKeepChildTop (since 0.9.29).
104	92
105	93		## AutoSize and Forms
106	94
107	95		Forms without Parent are controlled by the window manager and can therefore not be placed or resized freely. Setting the size is only a recommendation and might be ignored by the window manager. For example you might set the Width of a Form to 1000 and the widgetset might answer with a resize to 800. If you set the Width in OnResize you might create an endless loop. That's why the LCL TForm disables AutoSize when the widgetset resizes the form.
108	96
109	97		That means AutoSize for forms stops when the user resizes the form or if the window manager does not like the bounds. For example some Linux window managers have features like magnetic sides which resizes windows in relationship to other windows.
110	98
111	99		### Force an auto sizing of a form
112	100
113	101		You can start/execute a new AutoSize by doing:
114	102
115	103		``` pascal
116	104		Form1.AutoSize := False;
117	105		Form1.AutoSize := True;
118	106		```
119	107
120	108		### Compute the size of an autosized form in advance
121	109
122	110		When placing an autosized form you might need the size of the form before showing it. Autosizing requires the handle. You can compute the size of a form before showing it with:
123	111
124	112		``` pascal
125	113		From1.HandleNeeded;
126	114		Form1.GetPreferredSize(PreferredWidth,PreferredHeight);
127	115		```
128	116
129	117		Note: The window manager and form events might change the size. The preferred size does not include the form's window borders. This is a planned feature.
130	118
131	119		# Anchor Sides
132	120
133	121		Controls have four sides: akLeft, akTop, akRight and akBottom. Each side can be anchored to the parent or the side of another sibling (a control with the same parent). Anchoring means keeping the distance. The default is Anchors=\[akLeft,akTop\]. Vertical anchors are independent of horizontal anchors. Some properties like Align and Parent.AutoSize have higher precedence and can change the behaviour.
134	122
135	123		## Anchored to Parent or Nil
136	124
137	125		Anchoring to Nil (the default) has almost the same effect as anchoring to the Parent. Both try to keep the distance to a side of the Parent's client area. Anchoring to Nil uses the distance of the last SetBounds call, while Anchoring to Parent uses the BorderSpacing value.
138	126
139	127		There are four combinations of akLeft,akRight (akTop,akBottom):
140	128
141	129		- akLeft, no akRight: the control's Left is fixed and not changed by the LCL. The right side is not anchored, so it follows the left side. That means the Width is kept too.
142	130		- akLeft and akRight: the control's Left is fixed and not changed by the LCL. The right side is anchored to the Parent's right side. That means if the Parent is enlarged by 100pixel then the control's Width is enlarged by 100pixel too.
143	131		- akRight, no akLeft: the control's left side is not anchored, so it will follow its right side. The right side is anchored. That means if the parent is enlarged by 100pixel then the control is moved to the right by 100pixel.
144	132		- no akLeft and no akRight: neither sides are anchored. The position of the center of the control scales with the parent. For example if the control is in the middle of the parent and the parent is enlarged by 100 pixel, then the control is moved 50pixel to the right.
145	133
146	134		### Changing the size of the parent of an anchored control
147	135
148	136		A GroupBox with a Button: ![](/wiki-images/6/60/Anchors1.png)
149	137
150	138		When the GroupBox is enlarged the distance of the anchored side is kept:
151	139
152	140		With akLeft, no akRight: ![](/wiki-images/0/05/Anchors_akLeft.png)
153	141
154	142		With akLeft and akRight: ![](/wiki-images/6/66/Anchors_akLeft_akRight.png)
155	143
156	144		With akRight, no akLeft: ![](/wiki-images/d/d3/Anchors_akRight_no_akLeft.png)
157	145
158	146		Three buttons in a groupbox: ![](/wiki-images/4/48/Anchors_no_akLeft_no_akRight_small.png)
159	147
160	148		With no akLeft and no akRight their centers are scaled: ![](/wiki-images/7/7b/Anchors_no_akLeft_no_akRight_big.png)
161	149
162	150		### Changing the size of an anchored control
163	151
164	152		When changing the Width of an anchored control, for example via the Object Inspector or via code Button1.Width:=3, you can see the difference between anchoring to Parent and anchoring to Nil. Anchoring to Parent will resize and move the Button1, while anchoring to Nil will only resize. For example:
165	153
166	154		#### Anchored to nil
167	155
168	156		![](/wiki-images/b/bd/Anchored_right_nil_resize1.png) A Button1 anchored \[akTop,akRight\], AnchorSide\[akRight\].Control=nil
169	157
170	158		![](/wiki-images/a/a0/Anchored_right_nil_resize2.png) Setting the Width to a smaller value will shrink the button, keeping the button's Left, increasing the distance of the right side.
171	159
172	160		![](/wiki-images/1/16/Anchored_right_nil_resize3.png) When the Groupbox is resized the button will keep the new distance.
173	161
174	162		Explanation: setting the Width is equivalent to calling SetBounds(Left,Top,NewWidth,Height). That's why the Left is kept. This is Delphi compatible.
175	163
176	164		#### Anchored to Parent
177	165
178	166		![](/wiki-images/4/45/Anchored_right_parent_resize1.png) A Button1 anchored \[akTop,akRight\], AnchorSide\[akRight\].Control=Button1.Parent
179	167
180	168		![](/wiki-images/0/04/Anchored_right_parent_resize2.png) Setting the Width to a smaller value will shrink the button, keeping the right distance, changing the button's Left.
181	169
182	170		## Anchored to sibling
183	171
184	172		You can anchor to neighbor controls. The following example shows:
185	173
186	174		- you can anchor a label's left to the left of a button
187	175		- anchor a label's top to the bottom of a button
188	176		- anchor the center of a label to the center of a button
189	177
190		-	~~<figure>~~
191		-	~~<img src="Anchorsides_example1.png" title="Anchorsides_example1.png" />~~
192		-	~~<figcaption>Anchorsides_example1.png</figcaption>~~
193		-	~~</figure>~~
	178	+	![](/wiki-images/e/ee/Anchorsides_example1.png)
194	179
195		-	~~<figure>~~
196		-	~~<img src="Anchorside_example2.png" title="Anchorside_example2.png" />~~
197		-	~~<figcaption>Anchorside_example2.png</figcaption>~~
198		-	~~</figure>~~
	180	+	![](/wiki-images/b/ba/Anchorside_example2.png)
199	181
200	182		For more details and how to setup anchors see: [[Anchor Sides]].
201	183
202		-	~~<figure>~~
203		-	~~<img src="Anchoreditor.png" title="Anchoreditor.png" />~~
204		-	~~<figcaption>Anchoreditor.png</figcaption>~~
205		-	~~</figure>~~
	184	+	![](/wiki-images/6/6d/Anchoreditor.png)
206	185
207	186		## BorderSpacing
208	187
209	188		The BorderSpacing properties controls the minimum amount of space around a control. The properties are:
210	189
211	190		- Around: this amount in pixel is added to Left, Top, Right, Bottom.
212	191		- Left: space in pixel on the left side of the control
213	192		- Top: space in pixel above the control
214	193		- Right: space in pixel on the right side of the control
215	194		- Bottom: space in pixel below the control
216	195		- InnerBorder: this amount in pixel is added twice to the preferred width and height. Some controls override the calculation and ignore this property. An example where it works is TButton. With InnerBorder you can make a button bigger than needed.
217	196		- CellAlignHorizontal: This is used in table layouts like ChildSizing.Layout=cclLeftToRightThenTopToBottom. If the control is smaller than the table cell, this property defines where to align the control: to the left ccaLeftTop, to the right ccaRightBottom or in the middle ccaCenter.
218	197		- CellAlignVertical: same as CellAlignHorizontal but for vertical alignment.
219	198
220	199		### BorderSpacing rules
221	200
222	201		- Around is added to Left,Top,Right,Bottom
223	202		- The horizontal space between two controls (LeftControl, RightControl on Parent) is the maximum of
224	203		- LeftControl.BorderSpacing.Right + LeftControl.BorderSpacing.Around
225	204		- RightControl.BorderSpacing.Left + RightControl.BorderSpacing.Around
226	205		- Parent.ChildSizing.HorizontalSpacing
227	206
228	207		For instance if LeftControl.BorderSpacing.Right = 3 and LeftControl.BorderSpacing.Around = 4, then there is at least 7 pixel space between the two controls. If RightControl.BorderSpacing.Left = 4 and RightControl.BorderSpacing.Around = 4 then the space will be at least 8. If Parent.ChildSizing.HorizontalSpacing = 10 then the space will be at least 10.
229	208
230	209		Note: The space can be even bigger, if the controls have constraints that don't allow to expand.
231	210
232	211		A common example is anchoring a Label to an Edit.
233	212
234		-	~~<figure>~~
235		-	~~<img src="BorderSpacing_Anchors.png" title="BorderSpacing_Anchors.png" />~~
236		-	~~<figcaption>BorderSpacing_Anchors.png</figcaption>~~
237		-	~~</figure>~~
	213	+	![](/wiki-images/1/1e/BorderSpacing_Anchors.png)
238	214
239	215		The Label center is vertically anchored to the Edit. The Edit's left side is anchored to the right side of the Label. Both have BorderSpacing.Around=6. This results in 6 pixel space between the Label and the Edit and 6 pixel space left of the Label and 6 pixel space right of the Edit. There is 6 pixel space above and below the Edit as well.
240	216
241	217		- The left space between a control and its parent (Label1 on GroupBox1) is the maximum of
242	218		- Label1.BorderSpacing.Left + Label1.BorderSpacing.Around
243	219		- GroupBox1.ChildSizing.LeftTopSpacing
244	220
245	221		- The right space between a control and its parent (Edit1 on GroupBox1) is the maximum of
246	222		- Edit1.BorderSpacing.Right + Edit1.BorderSpacing.Around
247	223		- GroupBox1.ChildSizing.RightBottomSpacing
248	224
249	225		- When a control's center is anchored to another control, for example the above Label is centered vertically to the Edit1, then all spacings are ignored.
250	226
251	227		- When a control's left side is anchored to the left side of another control (i.e. they are aligned with the left side), then the space is the maximum of
252	228		- Control1.BorderSpacing.Left + Control1.BorderSpacing.Around
253	229		- Control2.BorderSpacing.Left + Control2.BorderSpacing.Around
254	230
255	231		Here is a more complex example:
256	232
257		-	~~<figure>~~
258		-	~~<img src="Borderspacing_anchors2.png" title="Borderspacing_anchors2.png" />~~
259		-	~~<figcaption>Borderspacing_anchors2.png</figcaption>~~
260		-	~~</figure>~~
	233	+	![](/wiki-images/9/9c/Borderspacing_anchors2.png)
261	234
262	235		The important parts of the lfm code:
263	236
264	237		``` pascal
265	238		object GroupBox1: TGroupBox
266	239		AutoSize = True
267	240		Caption = 'GroupBox1'
268	241		TabOrder = 0
269	242		object Label1: TLabel
270	243		AnchorSideLeft.Control = GroupBox1
271	244		AnchorSideTop.Control = Edit1
272	245		AnchorSideTop.Side = asrCenter
273	246		BorderSpacing.Around = 6
274	247		Caption = 'Label1'
275	248		end
276	249		object Edit1: TEdit
277	250		AnchorSideLeft.Control = Label1
278	251		AnchorSideLeft.Side = asrBottom
279	252		AnchorSideTop.Control = GroupBox1
280	253		AnchorSideRight.Control = GroupBox1
281	254		AnchorSideRight.Side = asrBottom
282	255		Anchors = [akTop, akLeft, akRight]
283	256		BorderSpacing.Around = 6
284	257		TabOrder = 0
285	258		Text = 'Edit1'
286	259		end
287	260		object Label2: TLabel
288	261		AnchorSideLeft.Control = GroupBox1
289	262		AnchorSideTop.Control = Edit1
290	263		AnchorSideTop.Side = asrBottom
291	264		BorderSpacing.Around = 6
292	265		Caption = 'Label2'
293	266		end
294	267		object ComboBox1: TComboBox
295	268		AnchorSideLeft.Control = Label2
296	269		AnchorSideTop.Control = Label2
297	270		AnchorSideTop.Side = asrBottom
298	271		AnchorSideRight.Control = GroupBox1
299	272		AnchorSideRight.Side = asrBottom
300	273		Anchors = [akTop, akLeft, akRight]
301	274		BorderSpacing.Right = 6
302	275		TabOrder = 1
303	276		Text = 'ComboBox1'
304	277		end
305	278		object CheckBox1: TCheckBox
306	279		AnchorSideLeft.Control = GroupBox1
307	280		AnchorSideTop.Control = ComboBox1
308	281		AnchorSideTop.Side = asrBottom
309	282		BorderSpacing.Around = 6
310	283		Caption = 'CheckBox1'
311	284		TabOrder = 2
312	285		end
313	286		object Label3: TLabel
314	287		AnchorSideLeft.Control = GroupBox1
315	288		AnchorSideTop.Control = Edit2
316	289		AnchorSideTop.Side = asrCenter
317	290		BorderSpacing.Around = 6
318	291		Caption = 'Label3'
319	292		end
320	293		object Edit2: TEdit
321	294		AnchorSideLeft.Control = Label3
322	295		AnchorSideLeft.Side = asrBottom
323	296		AnchorSideTop.Control = CheckBox1
324	297		AnchorSideTop.Side = asrBottom
325	298		BorderSpacing.Around = 6
326	299		TabOrder = 3
327	300		Text = 'Edit2'
328	301		end
329	302		end
330	303		```
331	304
332	305		### BorderSpacing and Align
333	306
334	307		BorderSpacing works with Align. In the example below there is a Memo1 with Align=alTop and a Memo2 with Align=alCLient.
335	308
336	309		- Normally the two Memos would fill the whole GroupBox.
337	310		- But the Memo1 has BorderSpacing.Around=10, so there 10 pixel space around Memo1.
338	311		- The Memo2 has BorderSpacing.Top=20. The space between Memo1 and Memo2 is the maximum, which is the 20 from Memo2.
339	312		- Memo2 has also BorderSpacing.Right=50 so there is 50 Pixel space right of Memo2.
340	313		- The GroupBox can define default space for all its child controls via ChildSizing.LeftRightSpacing/VerticalSpacing/HorizontalSpacing. In this example it does not (all 0).
341	314
342		-	~~<figure>~~
343		-	~~<img src="Borderspacing_align1.png" title="Borderspacing_align1.png" />~~
344		-	~~<figcaption>Borderspacing_align1.png</figcaption>~~
345		-	~~</figure>~~
	315	+	![](/wiki-images/1/13/Borderspacing_align1.png)
346	316
347	317		# Align
348	318
349	319		The Align property works pretty much like in Delphi and can be used to quickly fill an area. For example to let a TListBox fill the entire area of its Parent, set ListBox1.Align=alClient. The align values alTop, alBottom, alLeft and alRight will place controls without overlapping if possible. That means all controls with Align in alLeft,alTop,alBottom,alRight will not overlap if there is enough space.
350	320
351	321		The algorithm works as follows:
352	322
353	323		- First all controls with alTop are put to the top of the client area. If there are several controls with alTop the last added/moved will be put topmost. The algorithm will try to avoid overlapping and keep the height of the control, while expanding the width to maximum. AnchorSides of the left, top and right sides are ignored. The bottom AnchorSide works normal. Borderspacing and Parent.ChildSizing spaces are considered, so you can define space around each aligned control.
354	324		- Then all controls with alBottom are put to the bottom of the client area. Otherwise it works analog to alTop.
355	325		- Then all controls with alLeft are put to the left of the client area between the alTop and alBottom controls. Otherwise it works analog to alTop.
356	326		- Then all controls with alRight are put to the right of the client area between the alTop and alBottom controls. Otherwise it works analog to alTop.
357	327		- If there is a control with alClient it will fill the remaining client.
358	328		- If there is more than one control with alClient they will be placed at the same position, overlapping each other. Use the Visibility property to define which one is shown.
359	329
360		-	~~<figure>~~
361		-	~~<img src="Autosize_align.png" title="Autosize_align.png" />~~
362		-	~~<figcaption>Autosize_align.png</figcaption>~~
363		-	~~</figure>~~
	330	+	![](/wiki-images/e/e6/Autosize_align.png)
364	331
365	332		## Align and BorderSpacing
366	333
367	334		The space of BorderSpacing and of the parent's ChildSizing is applied to aligned controls. The memo below has Align=alClient.
368	335
369		-	~~<figure>~~
370		-	~~<img src="Autosize_align_borderspacing.png" title="Autosize_align_borderspacing.png" />~~
371		-	~~<figcaption>Autosize_align_borderspacing.png</figcaption>~~
372		-	~~</figure>~~
	336	+	![](/wiki-images/b/b4/Autosize_align_borderspacing.png)
373	337
374	338		## Align and Anchoring
375	339
376	340		The free side of an aligned control (e.g. the right side of a Align=alLeft) follows the anchoring rules. If the anchor is not set, then the control will keep its Width. If the anchor is set, then the Width will change.
377	341
378	342		## Align and AutoSize
379	343
380	344		A control aligned with alLeft or alRight expands vertically, and will use its designed width. If AutoSize is set to true, then the Width will be the preferred width. The button below has Align=alRight and AutoSize=true.
381	345
382		-	~~<figure>~~
383		-	~~<img src="Autosize_align_autosize.png" title="Autosize_align_autosize.png" />~~
384		-	~~<figcaption>Autosize_align_autosize.png</figcaption>~~
385		-	~~</figure>~~
	346	+	![](/wiki-images/3/35/Autosize_align_autosize.png)
386	347
387	348		## Align and parent AutoSize
388	349
389	350		A control aligned with alClient fills the remaining space. A parent control with AutoSize=true will expand or shrink to enclose its children exactly. What happens if you combine these two properties? Say you put a button with Align=alClient into a groupbox with AutoSize=true?
390	351
391		-	~~<figure>~~
392		-	~~<img src="Autosize_nested1.png" title="Autosize_nested1.png" />~~
393		-	~~<figcaption>Autosize_nested1.png</figcaption>~~
394		-	~~</figure>~~
	352	+	![](/wiki-images/b/b1/Autosize_nested1.png)
395	353
396	354		The LCL uses the preferred size of the buttons and expands or shrinks the groupbox accordingly:
397	355
398		-	~~<figure>~~
399		-	~~<img src="Autosize_nested2.png" title="Autosize_nested2.png" />~~
400		-	~~<figcaption>Autosize_nested2.png</figcaption>~~
401		-	~~</figure>~~
	356	+	![](/wiki-images/2/28/Autosize_nested2.png)
402	357
403	358		## alCustom
404	359
405	360		This Align value exists for custom AutoSize algorithms and is treated by the LCL almost like alNone. Controls with alCustom are not moved by the LCL but by your custom control. You have to override CalculatePreferredSize and DoAutoSize.
406	361
407	362		## Order of controls with same Align
408	363
409	364		Controls with same Align are added in the following order. On alLeft the control with the lowest Left wins, for alTop the lowest Top, for alRight the biggest Left+Width, for alBottom the biggest Top+Height. If two controls have the same coordinate the one last moved (calls to SetBounds or SetParent) wins. Controls can override CreateControlAlignList to change the order or override DoAlignChildControls to handle the whole Align.
410	365
411	366		Note: Before 0.9.29 controls at the same coordinate were put in Z order. This resulted in reordering in some cases and had to be fixed. There is one incompatibility: If you added several controls with alTop or alLeft without specifying bounds the controls are put at 0,0 and therefore the last added wins, where formerly the first won.
412	367
413	368		# Layout
414	369
415	370		## Rows, columns and lines
416	371
417	372		You can align child controls in rows and columns using the ChildSizing properties. For example:
418	373
419	374		- ChildSizing.Layout=cclLeftToRightThenTopToBottom
420	375		- ChildSizing.ControlsPerLine=3
421	376		- AutoSize=false (the groupbox does not fit the childs)
422	377
423		-	~~<figure>~~
424		-	~~<img src="Autosize_layout_lefttoright.png" title="Autosize_layout_lefttoright.png" />~~
425		-	~~<figcaption>Autosize_layout_lefttoright.png</figcaption>~~
426		-	~~</figure>~~
	378	+	![](/wiki-images/1/10/Autosize_layout_lefttoright.png)
427	379
428	380		The Layout property defaults to cclNone. If you set Layout to another value, every child, that has normal anchors, will be aligned. Normal anchors means:
429	381
430	382		- Anchors=\[akLeft,akTop\]
431	383		- AnchorSide\[akLeft\].Control=nil
432	384		- AnchorSide\[akTop\].Control=nil
433	385		- Align=alNone
434	386
435	387		The value cclLeftToRightThenTopToBottom will put the first child at top, left, the second to the right, and so forth. This is a line. The property ControlsPerLine defines when a new line is started. In the above example each line (row) has 3 controls. There are 12 controls, so there are 4 lines (rows) each with 3 controls (columns). If ControlsPerLine is 0 it means unlimited controls per line - there would be only one row with all childs.
436	388
437	389		You can see that the rows have different sizes, each row has the size of the biggest control and that the controls are resized to column width. There is no space between the rows. The space in the image comes from the used theme, not from the LCL.
438	390
439	391		## Fixed space between rows and columns
440	392
441	393		You can add space between with these properties:
442	394
443	395		- ChildSizing.VerticalSpacing - Space between rows
444	396		- ChildSizing.HorizontalSpacing - Space between columns
445	397		- ChildSizing.LeftRightSpacing - Space on the left and right of all columns
446	398		- ChildSizing.TopBottomSpacing - Space above and below of all columns
447	399
448	400		The above example with ChildSizing.VerticalSpacing=6, ChildSizing.HorizontalSpacing=15, ChildSizing.LeftRightSpacing=30, ChildSizing.TopBottomSpacing=10, AutoSize=true
449	401
450		-	~~<figure>~~
451		-	~~<img src="Autosize_layout_parentspacing.png" title="Autosize_layout_parentspacing.png" />~~
452		-	~~<figcaption>Autosize_layout_parentspacing.png</figcaption>~~
453		-	~~</figure>~~
	402	+	![](/wiki-images/a/a9/Autosize_layout_parentspacing.png)
454	403
455	404		Additionally you can add individual space for each control with its BorderSpacing properties.
456	405
457	406		## Enlarge
458	407
459	408		The above example resized the GroupBox to the needed space. If your GroupBox has a fixed size or if it is not freely resizable, for instance if the GroupBox should fill the whole width of the form, then the childs should enlarge. There are several modes. The default mode ChildSizing.EnlargeHorizontal=crsAnchorAligning is to not enlarge anything. The space on the right side will be unused.
460	409
461	410		- crsAnchorAligning - do not use the extra space
462	411		- crsScaleChilds - multiply the width/height with the same factor
463	412		- crsHomogeneousChildResize - add to each width/height the same amount
464	413		- crsHomogeneousSpaceResize - add to each space between the childs the same amount
465	414
466	415		### crsScaleChilds
467	416
468	417		ChildSizing.EnlargeHorizontal=crsScaleChilds, ChildSizing.EnlargeVertical=crsScaleChilds, AutoSize=false
469	418
470		-	~~<figure>~~
471		-	~~<img src="Autosize_layout_scalechilds.png" title="Autosize_layout_scalechilds.png" />~~
472		-	~~<figcaption>Autosize_layout_scalechilds.png</figcaption>~~
473		-	~~</figure>~~
	419	+	![](/wiki-images/b/b0/Autosize_layout_scalechilds.png)
474	420
475	421		For example if the ClientWidth is twice as big as needed, then every child will be twice as big.
476	422
477	423		### crsHomogeneousChildResize
478	424
479	425		ChildSizing.EnlargeHorizontal=crsHomogeneousChildResize, ChildSizing.EnlargeVertical=crsHomogeneousChildResize, AutoSize=false
480	426
481		-	~~<figure>~~
482		-	~~<img src="Autosize_layout_homogeneouschildresize.png" title="Autosize_layout_homogeneouschildresize.png" />~~
483		-	~~<figcaption>Autosize_layout_homogeneouschildresize.png</figcaption>~~
484		-	~~</figure>~~
	427	+	![](/wiki-images/3/39/Autosize_layout_homogeneouschildresize.png)
485	428
486	429		For example if the ClientWidth is 30 pixel bigger than needed, then every child will be 10 pixel broader.
487	430
488	431		### crsHomogeneousSpaceResize
489	432
490	433		ChildSizing.EnlargeHorizontal=crsHomogeneousSpaceResize, ChildSizing.EnlargeVertical=crsHomogeneousSpaceResize, AutoSize=false
491	434
492		-	~~<figure>~~
493		-	~~<img src="Autosize_layout_homogeneousspaceresize.png" title="Autosize_layout_homogeneousspaceresize.png" />~~
494		-	~~<figcaption>Autosize_layout_homogeneousspaceresize.png</figcaption>~~
495		-	~~</figure>~~
	435	+	![](/wiki-images/9/96/Autosize_layout_homogeneousspaceresize.png)
496	436
497	437		For example if the ClientWidth is 40 pixel bigger than needed, there will be 10 pixel space on the left, right and between each child.
498	438
499	439		## Shrink
500	440
501	441		Shrinking works similar to enlarging. You can set different modes if there is not enough space for controls. ShrinkHorizontal, ShrinkVertical.
502	442
503	443		## Individual cells
504	444
505	445		In the above examples all controls were resized the same, each filled the whole cell. A cell is the space in a specific row and column. Normally a control fills the whole cell space. This can be changed with the properties BorderSpacing.CellAlignHorizontal and BorderSpacing.CellAlignVertical.
506	446
507	447		For example set the BorderSpacing.CellAlignHorizontal of the fifth button to caCenter you will get this:
508	448
509		-	~~<figure>~~
510		-	~~<img src="Autosize_layout_cellhorizontal_cacenter.png" title="Autosize_layout_cellhorizontal_cacenter.png" />~~
511		-	~~<figcaption>Autosize_layout_cellhorizontal_cacenter.png</figcaption>~~
512		-	~~</figure>~~
	449	+	![](/wiki-images/d/d3/Autosize_layout_cellhorizontal_cacenter.png)
513	450
514	451		There are four possible values for CellAlignHorizontal/CellAlignVertical:
515	452
516	453		- caFill: the child control fills the whole width (height) of the cell
517	454		- caCenter: the child control uses its preferred width (height) and will be centered in the cell
518	455		- caLeftTop: the child control uses its preferred width (height) and will be leftaligned in the cell
519	456		- caRightBottom: the child control uses its preferred width (height) and will be rightaligned in the cell
520	457
521		-	~~<figure>~~
522		-	~~<img src="Autosize_layout_cellalign.png" title="Autosize_layout_cellalign.png" />~~
523		-	~~<figcaption>Autosize_layout_cellalign.png</figcaption>~~
524		-	~~</figure>~~
	458	+	![](/wiki-images/c/c0/Autosize_layout_cellalign.png)
525	459
526	460		# Custom layout with OnResize / OnChangeBounds
527	461
528	462		Sometimes the LCL layout is not sufficient. The below example shows a GroupBox1 with a ListBox1 and a Memo1. The ListBox1 should fill one third of the space, the Memo1 takes the rest.
529	463
530		-	~~<figure>~~
531		-	~~<img src="Autosize_onresize.png" title="Autosize_onresize.png" />~~
532		-	~~<figcaption>Autosize_onresize.png</figcaption>~~
533		-	~~</figure>~~
	464	+	![](/wiki-images/4/4b/Autosize_onresize.png)
534	465
535	466		Whenever the GroupBox is resized the ListBox1.Width should be one third. To achieve this set the OnResize event of the GroupBox1 to:
536	467
537	468		``` pascal
538	469		procedure TForm1.GroupBox1Resize(Sender: TObject);
539	470		begin
540	471		ListBox1.Width := GroupBox1.ClientWidth div 3;
541	472		end;
542	473		```
543	474
544	475		### Common mistake: Wrong OnResize event
545	476
546	477		Do not put all your resizing code into the Form OnResize event. The Form OnResize event is only called when the Form was resized. The child controls (e.g. a GroupBox1) is resized later, so the GroupBox1.ClientWidth has still the old value during the FormResize event. You must use the GroupBox1.OnResize event to react to changes of GroupBox1.ClientWidth.
547	478
548	479		### Common mistake: Width instead of ClientWidth, AdjustClientRect
549	480
550	481		The Width is the size including the frame. The ClientWidth is the inner Width without the frame. Some controls like the TPanel paints a further frame. Then you have to use AdjustClientRect. The same example, but instead of a GroupBox1 the ListBox1 is in a Panel1:
551	482
552	483		``` pascal
553	484		procedure TForm1.Panel1Resize(Sender: TObject);
554	485		var
555	486		r: TRect;
556	487		begin
557	488		r := Panel1.ClientRect;
558	489		Panel1.AdjustClientRect(r);
559	490		ListBox1.Width := (r.Right - r.Left) div 3;
560	491		end;
561	492		```
562	493
563	494		# Custom Controls
564	495
565	496		When you write your own control, you can override and fine tune many parts of the LCL autosizing.
566	497
567	498		## SetBounds, ChangeBounds, DoSetBounds
568	499
569	500		SetBounds is called when the properties Left, Top, Width, Height, BoundsRect is set or the user calls it directly. SetBounds updates the BaseBounds and BaseParentClientSize, which are used by anchoring to keep the distance. For example loading a Form with TMemo and the lfm contains TMemo's Left and Width, then SetBounds is called two times for the memo. When the user maximizes a window, SetBounds is called for the form, but not for the Memo, keeping the BaseBounds of the Memo. If the Memo is anchored to the right, the Width of the Memo is changed based on the BaseBounds and BaseParentClientSize. Keep in mind that the given aLeft, aTop, aWidth, aHeight might not be valid and will be changed by the LCL before applied. Delphi calls SetBounds more often. SetBounds calls ChangeBounds with KeepBase=false.
570	501
571	502		ChangeBounds is called whenever the position or size of the control is set, either via the properties or by the layouter of the LCL. SetBounds calls internally ChangeBounds with KeepBase=false, while the LCL layouter calls it with KeepBase=true. Override this for code that might change the preferred size or resizes other controls. Keep in mind that the given aLeft, aTop, aWidth, aHeight might not be valid and will be changed by the LCL before applied. You can call this function.
572	503
573	504		DoSetBounds is a low level function to set the private variables FLeft, FTop, FWidth, FHeight. Do not call this function, only the LCL calls it. It also updates FClientWidth and FClientHeight accordingly. Override this to update the content layout of the control, for example scroll bars. As always: do not paint here, but call Invalidate and paint in OnPaint or override Paint.
574	505
575	506		DoAdjustClientRectChange is called by the LCL and the LCL interface, when the ClientRect has changed and the Width and Height were kept.
576	507
577	508		WMSize exists for Delphi/VCL compatibility. It is called by the LCL interface and on every change of bounds.
578	509
579	510		## AdjustClientRect
580	511
581	512		The method AdjustClientRect can be overriden by your custom controls and affects Align, ChildSizing.Layout and AnchorSides. It does not affect the meaning of Left, Top and does not affect normal anchoring (for example setting).
582	513
583	514		When you want to draw your own frame, then the child controls should be aligned within these frames. For example TPanel draws a frame and reduces the client area by overriding the method AdjustClientRect:
584	515
585	516		``` pascal
586	517		TCustomPanel = class(TCustomControl)
587	518		...
588	519		protected
589	520		...
590	521		procedure AdjustClientRect(var aRect: TRect); override;
591	522		...
592	523
593	524		procedure TCustomPanel.AdjustClientRect(var aRect: TRect);
594	525		var
595	526		BevelSize: Integer;
596	527		begin
597	528		inherited AdjustClientRect(aRect);
598	529
599	530		BevelSize := BorderWidth;
600	531		if (BevelOuter <> bvNone) then
601	532		inc(BevelSize, BevelWidth);
602	533		if (BevelInner <> bvNone) then
603	534		inc(BevelSize, BevelWidth);
604	535
605	536		InflateRect(aRect, -BevelSize, -BevelSize);
606	537		end;
607	538		```
608	539
609	540		### AdjustClientRect and Align
610	541
611	542		AdjustClientRect can be used to reduce the client area used by all autosize operations. For example TPanel uses AdjustClientRect to reduce the client area by the borderwidth:
612	543
613		-	~~<figure>~~
614		-	~~<img src="Adjustclientrect_align.png" title="Adjustclientrect_align.png" />~~
615		-	~~<figcaption>Adjustclientrect_align.png</figcaption>~~
616		-	~~</figure>~~
	544	+	![](/wiki-images/c/ca/Adjustclientrect_align.png)
617	545
618	546		The Button1 in the screenshot was created with Align=alClient. ChildSizing.Layout is affected too.
619	547
620	548		When anchoring to a parent via AnchorSides the AdjustClientRect is used too:
621	549
622	550		``` pascal
623	551		Button1.AnchorParallel(akTop,0,Button1.Parent);
624	552		```
625	553
626	554		The Button1's top side is anchored to the top side of the parent's client area. If the AdjustClientRect adds 3 to the Top the Button1.Top will be 3 (3 plus 0).
627	555
628	556		## Own AutoSize
629	557
630	558		When AutoSize is set to true the control should be resized to the preferred size if possible.
631	559
632	560		### Preferred Size
633	561
634	562		The new size is fetched by the LCL via GetPreferredSize which calls CalculatePreferredSize, which can be overridden. For example let's write a TQuadrat, which is a TShape, but its height should equal its width:
635	563
636	564		``` pascal
637	565		TQuadrat = class(TShape)
638	566		protected
639	567		procedure CalculatePreferredSize(var PreferredWidth,
640	568		PreferredHeight: integer; WithThemeSpace: Boolean); override;
641	569		end;
642	570		...
643	571		procedure TQuadrat.CalculatePreferredSize(var PreferredWidth,
644	572		PreferredHeight: integer; WithThemeSpace: Boolean);
645	573		begin
646	574		PreferredHeight:=Width;
647	575		end;
648	576		```
649	577
650	578		The method CalculatePreferredSize gets two var parameters: PreferredWidth and PreferredHeight. They default to 0 which means: there is no preferred size, so the LCL will not change the size. The above function sets PreferredHeight to the current Width. The boolean parameter WithThemeSpace is deprecated and always false.
651	579
652	580		Important: CalculatePreferredSize must not change the bounds or any other value of the control that can trigger an autosize. Doing so will create a loop.
653	581
654	582		Computing the PreferredWidth/Height can be expensive. Therefore the LCL caches the result until InvalidatePreferredSize is called for the control. In our example the PreferredHeight depends on the Width, so we must invalidate when the Width changes:
655	583
656	584		``` pascal
657	585		TQuadrat = class(TShape)
658	586		protected
659	587		...
660	588		procedure DoSetBounds(ALeft, ATop, AWidth, AHeight: integer); override;
661	589		end;
662	590		...
663	591		procedure TQuadrat.DoSetBounds(ALeft, ATop, AWidth, AHeight: integer);
664	592		begin
665	593		inherited DoSetBounds(ALeft, ATop, AWidth, AHeight);
666	594		InvalidatePreferredSize;
667	595		// Note: The AdjustSize can be omitted here, because the LCL does that after calling DoSetBounds.
668	596		end;
669	597		```
670	598
671	599		The LCL will automatically trigger the autosizing when the bounds have changed, so the example is complete.
672	600
673	601		The default TWinControl implementation of CalculatePreferredSize queries the widgetset, which might return a preferred width and/or height. Each control can override the CalculatePreferredSize method. For example TImage overrides it and returns the size of the Picture. If no preferred width (height) is available the returned value is 0 and the LCL will keep the current Width (Height). If 0 is a valid size for your control, you must set the ControlStyle flag csAutoSize0x0 (ControlStyle:=ControlStyle+\[csAutoSize0x0\];). An example is the LCL control TPanel.
674	602
675	603		### AdjustSize
676	604
677	605		When the preferred size depends on a new property, then every time the property changes the auto sizing must be triggered. For example:
678	606
679	607		``` pascal
680	608		procedure TQuadrat.SetSubTitle(const AValue: string);
681	609		begin
682	610		if FSubTitle = AValue then exit;
683	611		FSubTitle := AValue;
684	612		InvalidatePreferredSize;
685	613		AdjustSize;
686	614		end;
687	615		```
688	616
689	617		# Reduce overhead with DisableAutoSizing, EnableAutoSizing
690	618
691	619		Since Lazarus 0.9.29 there is a new autosizing algorithm, that reduces the overhead and allows deep nested dependencies. Up to 0.9.28 DisableAlign/EnableAlign and Disable/EnableAutoSizing worked only for one control and its direct childs.
692	620
693	621		Each time you change a property the LCL triggers a recompute of the layout:
694	622
695	623		``` pascal
696	624		Label1.Caption := 'A'; // first recompute
697	625		Label2.Caption := 'B'; // second recompute
698	626		```
699	627
700	628		The recompute will trigger events and send messages. To reduce the overhead you can suspend the autosizing:
701	629
702	630		``` pascal
703	631		DisableAutoSizing;
704	632		try
705	633		Label1.Caption := 'A'; // no recompute
706	634		Label2.Caption := 'B'; // no recompute
707	635		finally
708	636		EnableAutoSizing; // one recompute
709	637		end;
710	638		```
711	639
712	640		The calls of Disable/EnableAutoSizing must be balanced. Only when EnableAutoSizing was called the same time as DisableAutoSizing the autosizing will start.
713	641
714	642		Since 0.9.29 the Disable/EnableAutoSizing work for the whole form. This means every call of DisableAutoSizing suspends the autosizing for all controls on the same form. If you write your own control you can now use the following:
715	643
716	644		``` pascal
717	645		procedure TMyRadioGroup.DoSomething;
718	646		begin
719	647		DisableAutoSizing; // disables not only TMyRadioGroup, but the whole form
720	648		try
721	649		// delete items ...
722	650		// add, reorder items ...
723	651		// change item captions ...
724	652		finally
725	653		EnableAutoSizing; // recompute
726	654		end;
727	655		end;
728	656		```
729	657
730	658		Which basically means: you do not have to care. Just call Disable/EnableAutoSizing.
731	659
732	660		Note: this is wrong:
733	661
734	662		``` pascal
735	663		Button1.DisableAutoSizing;
736	664		Label1.EnableAutoSizing; // wrong: every control has its own counter
737	665		```
738	666
739	667		## DisableAutoSizing and Form bounds
740	668
741	669		DisableAutoSizing has another useful effect under asynchronous Window Managers like the ones under Linux. Each time a form is resized or moved the bounds are sent to the widgetset (DoSendBoundsToInterface). Even if the form is not shown the Handle is resized. The window manager often treats these bounds only as proposal, the window manager has its own logic and often only the first bounds sent are used. The second, third or further moves may be ignored. With DisableAutoSizing you can make sure that only the final bounds are sent to the widgetset making the form bounds more reliable.
742	670
743	671		# Example: a button panel
744	672
745	673		This example combines several of the LCL layout mechanisms to create a panel with three buttons: a Help button to the left and Ok and Cancel buttons to the right. We want the panel to be at the bottom of the form filling the entire width. The buttons and the panel are autosized to fit all fonts and themes.
746	674
747	675		Step 1: Create the panel and set its Align property to alBottom. Add three TBitBtns.
748	676
749		-	~~<figure>~~
750		-	~~<img src="Autosize_example_buttonpanel1.png" title="Autosize_example_buttonpanel1.png" />~~
751		-	~~<figcaption>Autosize_example_buttonpanel1.png</figcaption>~~
752		-	~~</figure>~~
	677	+	![](/wiki-images/7/7e/Autosize_example_buttonpanel1.png)
753	678
754	679		Set the Kind properties of the BitBtns to show the glyphs. You might need to set GlyphShowMode to gsmAlways to see them on your platform. Set the BitBtn's AutoSize property to True, which will shrink/enlarge the buttons to fit perfectly around the glyphs and text. Depending on your theme and platform you might notice that the buttons have different heights.
755	680
756		-	~~<figure>~~
757		-	~~<img src="Autosize_example_buttonpanel2.png" title="Autosize_example_buttonpanel2.png" />~~
758		-	~~<figcaption>Autosize_example_buttonpanel2.png</figcaption>~~
759		-	~~</figure>~~
	681	+	![](/wiki-images/4/49/Autosize_example_buttonpanel2.png)
760	682
761	683		Set the Align property of the help button to alLeft and set the other two buttons' Align property to alRight. This will enlarge the buttons vertically and move them to the far left/right. alLeft/alRight has no effect on the width, so the buttons use their preferred width.
762	684
763		-	~~<figure>~~
764		-	~~<img src="Autosize_example_buttonpanel3.png" title="Autosize_example_buttonpanel3.png" />~~
765		-	~~<figcaption>Autosize_example_buttonpanel3.png</figcaption>~~
766		-	~~</figure>~~
	685	+	![](/wiki-images/b/b6/Autosize_example_buttonpanel3.png)
767	686
768	687		The Panel height is still fixed. Now set the panel AutoSize property to True. The panel now shrinks vertically to fit the tallest button.
769	688
770		-	~~<figure>~~
771		-	~~<img src="Autosize_example_buttonpanel4.png" title="Autosize_example_buttonpanel4.png" />~~
772		-	~~<figcaption>Autosize_example_buttonpanel4.png</figcaption>~~
773		-	~~</figure>~~
	689	+	![](/wiki-images/3/36/Autosize_example_buttonpanel4.png)
774	690
775	691		The Ok button has a short caption, so the button is very small. Set the button's Constraints.MinWidth to 75. The button will now enlarge somewhat.
776	692
777		-	~~<figure>~~
778		-	~~<img src="Autosize_example_buttonpanel5.png" title="Autosize_example_buttonpanel5.png" />~~
779		-	~~<figcaption>Autosize_example_buttonpanel5.png</figcaption>~~
780		-	~~</figure>~~
	693	+	![](/wiki-images/3/32/Autosize_example_buttonpanel5.png)
781	694
782	695		Now add some space around the buttons. Set the panel's ChildSizing.LeftTopSpacing/RightBottomSpacing/HorizontalSpacing to 6.
783	696
784		-	~~<figure>~~
785		-	~~<img src="Autosize_example_buttonpanel6.png" title="Autosize_example_buttonpanel6.png" />~~
786		-	~~<figcaption>Autosize_example_buttonpanel6.png</figcaption>~~
787		-	~~</figure>~~
	697	+	![](/wiki-images/4/46/Autosize_example_buttonpanel6.png)
788	698
789	699		Finally clear the Caption of the panel and set its BevelOuter to bvNone.
790	700
791		-	~~<figure>~~
792		-	~~<img src="Autosize_example_buttonpanel7.png" title="Autosize_example_buttonpanel7.png" />~~
793		-	~~<figcaption>Autosize_example_buttonpanel7.png</figcaption>~~
794		-	~~</figure>~~
	701	+	![](/wiki-images/4/4e/Autosize_example_buttonpanel7.png)
795	702
796	703		# Scrolling
797	704
798	705		Some LCL controls like TScrollBox, TForm, TFrame allows to show scrollbars if the child controls do not fit. They inherit the behavior from their ancestor TScrollingWinControl.
799	706
800	707		On a scrolling control the logical client area can be bigger than the visible client area. The visible client area is ClientRect. It always starts at 0,0 and its width and height is the inner area. For example in a TGroupBox it is the size of the area inside the frame. So the following is always true:
801	708
802	709		``` pascal
803	710		ClientWidth <= Width
804	711		ClientHeight <= Height
805	712		```
806	713
807	714		The logical client area is defined by the method GetLogicalClientRect. By default it is the same as ClientRect. When a child control is anchored to the right side, it uses the logical client area. TScrollingWinControl overrides this method and returns the Range of the scrollbars if they are bigger than the ClientRect. The Range can be set manually or automatically with AutoScroll=true. An example for AutoScroll=true:
808	715
809		-	~~<figure>~~
810		-	~~<img src="Autoscroll_all_fit1.png" title="Autoscroll_all_fit1.png" />~~
811		-	~~<figcaption>Autoscroll_all_fit1.png</figcaption>~~
812		-	~~</figure>~~
	716	+	![](/wiki-images/d/db/Autoscroll_all_fit1.png)
813	717
814	718		The upper button has a fixed Width of 200. The lower button is anchored to the right side of the panel. Therefore the child controls have a preferred width of 200. Because the panel is bigger than 200 the logical client area is bigger too and the lower button expands.
815	719
816	720		Now the panel is shrinked, so that the ClientWidth gets lower than 200:
817	721
818		-	~~<figure>~~
819		-	~~<img src="Autoscroll_not_fit1.png" title="Autoscroll_not_fit1.png" />~~
820		-	~~<figcaption>Autoscroll_not_fit1.png</figcaption>~~
821		-	~~</figure>~~
	722	+	![](/wiki-images/2/27/Autoscroll_not_fit1.png)
822	723
823	724		The preferred width is still 200, so the logical client area is now 200 and bigger than the visible client area. The lower button has now a Width of 200 and the panel shows a horizontal scrollbar.
824	725
825	726		## Scroll Position
826	727
827	728		Changing the Position of a scrollbar does not change the Left, Top of child controls, does not change the logical client area and has no effect on autosizing. The child controls are only virtually moved.
828	729
829	730		## Scrolling and AutoSize
830	731
831	732		When AutoSize=true the LCL will expand the control to fit all child controls and no scrollbars are needed. If the control can not be expanded, then only the second action of AutoSize is executed: moving the child controls.
832	733
833	734		# Docking
834	735
835	736		Docking uses the described methods and properties of this page, see [[Docking]].
836	737
837	738		# Splitter
838	739
839	740		See [[TSplitter]].
840	741
841	742		# TLabel.WordWrap
842	743
843	744		TLabel.WordWrap changes the behavior of the preferred size of the label. WordWrap=true requires that the Width of the label is fixed, for example by anchoring the left and right size of the label. The preferred height of the label is then computed by breaking the Caption into multiple lines.
844	745
845	746		# DPI auto-adjustment and absolute layout auto-adjustment
846	747
847	748		Historically the LCL has been utilized mostly to design absolute layouts, despite the huge amount of options which Lazarus offers for flexible layouts, like Align, Anchors, etc, as described on the rest of this article. On top of that, it has also historically ignored the DPI of the target and instead utilized values in pixels to measure the left, top, width and height properties of controls. For desktop platforms and Windows CE this has worked reasonably ok, but with the advent of LCL support for Android this could no longer be ignored. Starts in Lazarus 0.9.31 the LCL can reinterprete the LCL absolute layout in pixels as a flexible grid. There are multiple modes to choose from and they will allow to reinterprete the pixel values as either really absolute, or as in being adjusted for the DPI or as in being considered simply a fraction of the form size.
848	749
849	750		It is important to note that these new rules affect only controls which are positioned without Align and with the most standard Anchors only.
850	751
851	752		In the case where the values will be adjusted for DPI, there is a new property: TCustomForm.DesignTimeDPI which should store the DPI value of the system where the form was designed. The positoning values will be expanded when the target DPI is larger then the design time DPI or reduced otherwise. The common value for desktop DPIs is 96 and is the default value given.
852	753
853	754		property DesignTimeDPI: Integer read FDesignTimeDPI write FDesignTimeDPI;
854	755
855	756		The way in which the layout is adjusted can be controlled with the property TApplication.LayoutAdjustmentPolicy
856	757
857	758		` TLayoutAdjustmentPolicy = (`\
858	759		` lapDefault, // widgetset dependent`\
859	760		` lapFixedLayout, // A fixed absolute layout in all platforms`\
860	761		` lapAutoAdjustWithoutHorizontalScrolling, // Smartphone platforms use this one,`\
861	762		` // the x axis is stretched to fill the screen and`\
862	763		` // the y is scaled to fit the DPI`\
863	764		` lapAutoAdjustForDPI // For desktops using High DPI, scale x and y to fit the DPI`\
864	765		` );`
865	766
866	767		And the following new methods in TControl allow to force a layout-autoadjustment in a particular control and all its children or to control how particular descendents of TControl react to this:
867	768
868	769		``` pascal
869	770		TControl = class
870	771		public
871	772		...
872	773		procedure AutoAdjustLayout(AMode: TLayoutAdjustmentPolicy;
873	774		const AFromDPI, AToDPI, AOldFormWidth, ANewFormWidth: Integer); virtual;
874	775		function ShouldAutoAdjustLeftAndTop: Boolean; virtual;
875	776		function ShouldAutoAdjustWidthAndHeight: Boolean; virtual;
876	777		```
877	778
878	779		LCL-CustomDrawn-Android will call AutoAdjustLayout when the screen rotates, for example.
879	780
880	781		# More details
881	782
882	783		Many controls override TControl.DoAutoSize to perform the actual auto-sizing.
883	784
884	785		IMPORTANT: Many Delphi controls override this method and many call this method directly after setting some properties.
885	786
886	787		During handle creation not all interfaces can create complete Device Contexts which are needed to calculate things like text size.
887	788
888	789		That's why you should always call AdjustSize instead of `DoAutoSize`.
889	790
890	791		`TControl.AdjustSize` calls `DoAutoSize` in a smart fashion.
891	792
892	793		During loading and handle creation the calls are delayed.
893	794
894	795		This method initially does the same as TWinControl.DoAutoSize. But since `DoAutoSize` is commonly overriden by descendant components, it is not useful to perform all tests, which can result in too much overhead. To reduce this the LCL calls `AdjustSize` instead.
895	796
896	797		When setting AutoSize = true the LCL autosizes the control in width and height. This is one of the most complex parts of the LCL, because the result depends on nearly a hundred properties. Let's start simple:
897	798
898	799		The LCL will only autosize the Width (Height) if it is free to resize. In other words - the width is not autosized if:
899	800
900	801		- the left and right side is anchored. You can anchor the sides with the Anchors property or by setting the Align property to alTop, alBottom or alClient.
901	802		- the Width is bound by the Constraints properties. The Contraints can also be overriden by the widgetset. For example the winapi does not allow resizing the height of a combobox. And the gtk widgetset does not allow resizing the width of a vertical scrollbar.
902	803
903	804		Same for Height.
904	805
905	806		The new size is calculated by the protected method TControl.CalculatePreferredSize. This method asks the widgetset for an appropriate Width and Height. For example a TButton has preferred Width and Height. A TComboBox has only a preferred Height. The preferred Width is returned as 0 and so the LCL does not autosize the Width - it keeps the width unaltered. Finally a TMemo has no preferred Width or Height. Therefore AutoSize has no effect on a TMemo.
906	807
907	808		Some controls override this method. For example the TGraphicControl descendants like TLabel have no window handle and so cannot query the widgetset. They must calculate their preferred Width and Height themselves.
908	809
909	810		The widgetsets must override the GetPreferredSize method for each widget class that has a preferred size (Width or Height or both).
910	811
911	812		## Parent.AutoSize
912	813
913	814		The above described the simple explanation. The real algorithm provides far more possibilities and is therefore far more complex.
914	815
915	816		## Properties / Methods
916	817
917	818		- Left
918	819		- Top
919	820
920	821		If Parent\<\>nil then Left, Top are the pixel distance to the top, left pixel of the parent's client area (not scrolled). Remember the client area is always without the frame and scrollbars of the parent. For Delphi users: Some VCL controls like TGroupbox define the client area as the whole control including the frame and some not - the LCL is more consistent, and therefore Delphi incompatible. Left and Top can be negative or bigger than the client area. Some widgetsets define a minimum/maximum somewhere around 10.000 or more.
921	822
922	823		When the client area is scrolled the Left and Top are kept unchanged.
923	824
924	825		During resizing/moving Left and Top are not always in sync with the coordinates of the Handle object.
925	826
926	827		If Parent=nil then Left, Top depend on the widgetset and the window manager. Till Lazarus 0.9.25 this is typically the screen coordinate of the left,top of the client area of the form. This is Delphi incompatible. It is planned to change this to the Left, Top of the window.
927	828
928	829		Hint: Each time you change Left and Top the LCL moves instantly and recomputes the whole layout. If you want to change Left and Top use instead:
929	830
930	831		``` pascal
931	832		with Button1 do
932	833		SetBounds(NewLeft, NewTop, Width, Height);
933	834		```
934	835
935	836		- Width
936	837		- Height
937	838
938	839		The Size in pixels must not be negative, and most widgetsets do not allow Width=0 and/or Height=0. Some controls on some platforms define a bigger minimum constraint in Constraints.MinInterfaceWidth/Height. Instead of sizing a control to Width=0 and/or Height=0, set Visible=false or Parent=nil. During resizing/moving Width and Height are not always in sync with the size of the Handle object.
939	840
940	841		- BoundsRect
941	842
942	843		Same as Bounds(Left, Top, Width, Height).
943	844
944	845		Common newbie mistake:
945	846
946	847		``` pascal
947	848		BoundsRect.Left := 3; // WRONG: common newbie mistake
948	849		```
949	850
950	851		This has no effect, because reading BoundsRect is a function. It creates a temporary TRect on the stack. The above is the same as
951	852
952	853		``` pascal
953	854		var
954	855		r: TRect;
955	856		begin
956	857		r := BoundsRect; // fetch the bounds
957	858		r.Left := 3; // change a value on the stack
958	859		end; // no change
959	860		```
960	861
961	862		- ClientRect
962	863
963	864		Left and Top are always 0,0. Width and Height are the visible size in pixels of the client area. Remember the client area is without the frame and without scrollbars. In a scrollable client area the logical client area can be bigger than the visible.
964	865
965	866		- ClientOrigin
966	867
967	868		Returns the screen coordinate of the topleft coordinate 0,0 of the client area. Note that this value is the position as stored in the interface and is not always in sync with the LCL. When a control is moved, the LCL sets the bounds to the desired position and sends a move message to the interface. It is up to the interface to handle moves instantly or queued.
968	869
969	870		- LCLIntf.GetClientBounds
970	871
971	872		Returns the client bounds of a control. Like ClientRect, but Left and Top are the pixel distances to the control's left, top. For example on a TGroupBox the Left, Top are the width and height of the left and top frame border. Scrolling has no effect on GetClientBounds.
972	873
973	874		- LCLIntf.GetWindowRect
974	875
975	876		After the call, ARect will be the control area in screen coordinates. That means, Left and Top will be the screen coordinate of the TopLeft pixel of the Handle object and Right and Bottom will be the screen coordinate of the BottomRight pixel.
976	877
977	878		- FBaseBoundsLock: integer
978	879
979	880		Increased/Decreased by LockBaseBounds/UnlockBaseBounds. Used to keep FBaseBounds during SetBounds calls.
980	881
981	882		- FBaseParentClientSize: TPoint
982	883
983	884		The Parent.ClientRect size valid for the FBaseBounds. FBaseBounds and FBaseParentClientSize are used to calculate the distance for akRight (akBottom). When the parent is resized, the LCL knows what distance to keep.
984	885
985	886		- FBoundsRectForNewParent: TRect
986	887
987	888		When changing the Parent of a control the Handle is recreated and many things can happen. Especially for docking forms the process is too unreliable. Therefore the BoundsRect is saved. The VCL uses a similar mechanism.
988	889
989	890		- fLastAlignedBounds: TRect
990	891
991	892		See TControl.SetAlignedBounds for an explanation. In short: It stops some circles between interface and LCL autosizing.
992	893
993	894		- FLastChangebounds: TRect
994	895
995	896		Used to stop calling ChangeBounds with the same coordinates. This happens very often.
996	897
997	898		- FLastDoChangeBounds: TRect
998	899
999	900		Used to avoid calling OnChangeBounds with the same coordinates. This reduces user defined autosizing.
1000	901
1001	902		- FLastResizeClientHeight: integer
1002	903		- FLastResizeClientWidth: integer
1003	904		- FLastResizeHeight: integer
1004	905		- FLastResizeWidth: integer
1005	906
1006	907		Used to avoid calling OnResize with the same coordinates. This reduces user defined autosizing.
1007	908
1008	909		- FLoadedClientSize: TPoint
1009	910
1010	911		During loading many things are delayed and many things are set and worse: in the wrong order. That's why SetClientWidth/SetClientHeight calls are stored and set at end of loading again. This way the LCL can restore the distances (e.g. akRight) used during designing.
1011	912
1012	913		- FReadBounds: TRect
1013	914
1014	915		Same as FLoadedClientSize, but for SetLeft, SetTop, SetWidth, SetHeight.
1015	916
1016	917		- procedure SetBoundsRectForNewParent(const AValue: TRect);
1017	918
1018	919		Used to set FBoundsRectForNewParent. See above.
1019	920
1020	921		- procedure SetAlignedBounds(aLeft, aTop, aWidth, aHeight: integer); virtual;
1021	922
1022	923		As SetBounds but without changing the default sizes.
1023	924
1024	925		- procedure SetInitialBounds(aLeft, aTop, aWidth, aHeight: integer); virtual;
1025	926
1026	927		A smart version of SetBounds, reducing overhead during creation and loading.
1027	928
1028	929		- procedure UpdateBaseBounds(StoreBounds, StoreParentClientSize, UseLoadedValues: boolean); virtual;
1029	930
1030	931		Commit current bounds to base bounds.
1031	932
1032	933		- procedure SetClientHeight(Value: Integer);
1033	934		- procedure SetClientSize(Value: TPoint);
1034	935		- procedure SetClientWidth(Value: Integer);
1035	936
1036	937		Exists for Delphi compatibility too. Resizes the control, to get the wanted ClientRect size.
1037	938
1038	939		- procedure ChangeBounds(ALeft, ATop, AWidth, AHeight: integer); virtual;
1039	940
1040	941		This is the internal SetBounds. Applies constraints, updates base bounds, calls OnChangeBound, OnResize, locks bounds.
1041	942
1042	943		- procedure DoSetBounds(ALeft, ATop, AWidth, AHeight: integer); virtual;
1043	944
1044	945		This really sets the FLeft, FTop, FWidth, FHeight private variables.
1045	946
1046	947		- procedure SetBounds(aLeft, aTop, aWidth, aHeight: integer); virtual;
1047	948
1048	949		This is the standard procedure overriden by many Delphi controls. TWinControl overrides it too.
1049	950
1050	951		- - ignores calls when bounds are locked
1051	952		- lock the FBoundsRealized to avoid overhead to the interface during auto sizing.
1052	953
1053	954		ChangeBounds is not locked this way.
1054	955
1055	956		- Function GetClientOrigin: TPoint; virtual;
1056	957
1057	958		Screen coordinate of Left, Top of client area.
1058	959
1059	960		- Function GetClientRect: TRect; virtual;
1060	961
1061	962		Size of client area. (always Left=0, Top=0)
1062	963
1063	964		- Function GetScrolledClientRect: TRect; virtual;
1064	965
1065	966		Visible client area in ClientRect.
1066	967
1067	968		- function GetChildsRect(Scrolled: boolean): TRect; virtual;
1068	969
1069	970		Returns the Client rectangle relative to the control's Left, Top. If Scrolled is true, the rectangle is moved by the current scrolling values (for an example see TScrollingWincontrol).
1070	971
1071	972		- function GetClientScrollOffset: TPoint; virtual;
1072	973
1073	974		Returns the scrolling offset of the client area.
1074	975
1075	976		- function GetControlOrigin: TPoint; virtual;
1076	977
1077	978		Returns the screen coordinate of the topleft coordinate 0,0 of the control area. (The topleft pixel of the control on the screen) Note that this value is the position as stored in the interface and is not always in sync with the LCL. When a control is moved, the LCL sets the bounds to the wanted position and sends a move message to the interface. It is up to the interface to handle moves instantly or queued.
1078	979
1079	980		# FAQ
1080	981
1081	982		## Why does AutoSize not work in the designer properly?
1082	983
1083	984		In the designer controls can be dragged around and properties can be set in almost any order. To allow this and avoid possible conflicts, the AutoSizing is not updated on every change at design time.
1084	985
1085	986		## Why does TForm.AutoSize not work when something changes?
1086	987
1087	988		See [[Autosize / Layout\|AutoSize and Forms]]
1088	989
1089	990		## Do I need to call Application.ProcessMessages when creating lots of controls?
1090	991
1091	992		Application.ProcessMessages is called by the LCL automatically after every message (e.g. after every event like OnClick). Calling it yourself is only needed if the changes should become visible to the user immediately. For example:
1092	993
1093	994		\<DELPHI\>procedure TFrom.Button1Click(Sender: TObject); begin
1094	995
1095	996		` // change width of a control`\
1096	997		` Button1.Width := Button1.Width + 10;`\
1097	998		` // apply any needed changes and repaint the button`\
1098	999		` Application.ProcessMessages;`\
1099	1000		` // do a lot of things that takes a long time`\
1100	1001		` ...`\
1101	1002		` // after leaving the OnClick the LCL automatically processes messages`
1102	1003
1103	1004		end;\</DELPHI\>
1104	1005
1105	1006		## When enabling Anchors at runtime the control resizes, does not use the current values. Why?
1106	1007
1107	1008		akBottom means: keep a distance to the bottom side of the parent. The distance to keep is defined by the base bounds. They are set at designtime or by runtime calls of SetBounds or UpdateBaseBounds.
1108	1009
1109	1010		For example: A TListBox (Anchors=\[akLeft,aTop\]) at designtime has a bottom distance of 100 pixel. And a button to enable/disable the akBottom of the TListBox. Now start the application and press the button to enable akBottom. The 100 pixel distance will be activated, because this was the last time the programmer defined the base bounds of the TListBox. All other resizes were done by the LCL and are irrelevant. The programmers base bounds rules. You can resize the form and the 100 pixel will be kept. In order to use the current bounds as base bounds use:
1110	1011
1111	1012		``` pascal
1112	1013		ListBox1.UpdateBaseBounds(true, true, false);
1113	1014		ListBox1.Anchors := ListBox1.Anchors + [akBottom];
1114	1015		```
1115	1016
1116	1017		Setting Anchors does not automatically call UpdateBaseBounds, because this would destroy the ability to change properties independently.
1117	1018
1118	1019		## Resizing stringgrid columns in form's OnResize event does not work
1119	1020
1120	1021		The Form's OnResize is triggered when the Form's Width, Height, ClientWidth or ClientHeight changes. This is per se independent of TStringGrid. Of course it often happens that both the Form and the TStringGrid are resized. This means using forms OnResize will often work, but not always. A prominent example where it always fails is when the theme is changed and you have a TStringGrid in a TGroupBox in a TForm. When the theme changed the form size is kept, so no Forms OnResize is triggered. But the TGroupBox changed, so the TStringGrid should be resized.
1121	1022
1122	1023		Solution: Use the TStringGrid's OnResize.
1123	1024
1124	1025		## Why is TForm.Width equal to TForm.ClientWidth?
1125	1026
1126	1027		Mattias' notes:
1127	1028
1128	1029		"There are historical and technical reasons.
1129	1030
1130	1031		For forms without parent the Clientwidth equals the Width, because the real Width including the frame was not available on Linux ten years ago (at least not reliable on various window managers). I didn't test, but I heard it is now possible with gtk2. The main problem is the autosizing, because this needs the frame sizes before the form is mapped to the screen. It might be, that this is only available after an event, which means that you have to wait for it, which means trouble for ShowModal. Changing this breaks compatibility with a lot of existing LCL code, but for this we added the LCLVersion in the lfm files.
1131	1032
1132	1033		For all other controls the rules is ClientWidth\<=Width. The Width is the ClientWidth plus the widget frame. The question is if the scrollbars belong to the frame. I would say yes and it was implemented that way some time ago. Apparently this has changed. See the current cursor problem on synedit."
1133	1034
1134	1035		## I get an infinite loop / How to debug autosizing?
1135	1036
1136	1037		Here are some notes, what other users made wrong and how to find out:
1137	1038
1138	1039		### Differences to Delphi
1139	1040
1140	1041		For Delphi users: Please read: [[Autosize / Layout\|Difference to Delphi]]
1141	1042
1142	1043		### Overriding a LCL method and triggering a recompute
1143	1044
1144	1045		You override a method and tell the LCL to compute again, even if nothing changed. Check for AdjustSize, Realign, AlignControls, InvalidatePreferredSize. For example:
1145	1046
1146	1047		``` pascal
1147	1048		procedure TMainForm.SetBounds(ALeft, ATop, AWidth, AHeight: integer);
1148	1049		begin
1149	1050		// This will create an endless loop
1150	1051		InvalidatePreferredSize;
1151	1052
1152	1053		// This will create an endless loop too:
1153	1054		OtherComponent.Left:=10;
1154	1055		OtherComponent.Left:=20;
1155	1056
1156	1057		inherited SetBounds(ALeft, ATop, AWidth, AHeight);
1157	1058		end;
1158	1059		```
1159	1060
1160	1061		Explanation: The SetBounds method is called often, even without changing anything. For example a "Left:=30;" will do so.
1161	1062
1162	1063		Remedy: Check for changes:
1163	1064
1164	1065		``` pascal
1165	1066		procedure TMainForm.SetBounds(ALeft, ATop, AWidth, AHeight: integer);
1166	1067		begin
1167	1068		if (Left <> ALeft) or (Top <> ATop) or (Width <> AWidth) or (Height <> AHeight) then
1168	1069		InvalidatePreferredSize;
1169	1070		inherited SetBounds(ALeft, ATop, AWidth, AHeight);
1170	1071		end;
1171	1072		```
1172	1073
1173	1074		### OnResize/OnChangeBounds conflict with LCL properties
1174	1075
1175	1076		You set bounds that bite the LCL properties. For example a TLabel.AutoSize is true by default. If you set the Label1.Width in an OnResize event, the LCL will recompute, resize the Label1 and call the OnResize again. Start your application in the debugger and reproduce the bug. When it enters the loop, pause the application and see the call stack. If you see one of your events or your methods start searching there. For example:
1176	1077
1177	1078		``` pascal
1178	1079		procedure TMainForm.FormResize(Sender: TObject);
1179	1080		begin
1180	1081		// if Button1 is anchored or AutoSize=true then the following might create an endless loop:
1181	1082		Button1.Width:=100;
1182	1083		end;
1183	1084		```
1184	1085
1185	1086		### LCL interface bug, custom widget
1186	1087
1187	1088		Sometimes the LCL interface or your custom control has a bug and undoes the LCL bounds. Compile the LCL with -dVerboseIntfSizing. This will write the communication between LCL and the LCL interface. If a widget does not allow free resizing, it must tell the LCL via the Constraints. Search for SetInterfaceConstraints in the various LCL interfaces and TWSControlClass.ConstraintWidth/Height.
1188	1089
1189	1090		### alCustom
1190	1091
1191	1092		You use alCustom. This was only half implemented in earlier Lazarus versions, but some clever programmers used it to create some special effects. Now it is implemented and your program does not work anymore. Please see here what alCustom does: [[Autosize / Layout\|alCustom]].
1192	1093
1193	1094		# See also
1194	1095
1195	1096		- [[Docking]]
1196	1097		- [[Anchor Sides]]
1197	1098
1198	1099		---
1199	1100		From the Free Pascal wiki, page "Autosize / Layout/zh TW", as it stood on 2020-02-09 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history