[Lazarus] typecast to an empty local class

[Mattias Gaertner]

On Fri, 23 Apr 2010 20:06:29 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Mattias Gaertner schrieb:
> 
> >> Maybe I'm wrong (didn't look into), but seem that delphi/kylix triggers 
> >> form.OnResize when everything is resized inside form (children), or it 
> >> triggers twice : at form resize, and then after all children resized.
> > 
> > Don't forget that Delphi has a simple top down autosize algorithm. It
> > does not even support a theme independent groupbox with buttons.
> 
> Why requires theme support to break that stable processing?

It is not that "stable". It is simple and limited to simple layouts.

Maybe you don't know how the VCL resizes:
As soon as a size or position changes the layout must recomputed. This
is done by resizing the control itself and telling the parent to
realign its children. This can trigger other controls and so forth, a
random walk until nothing changes anymore. A control can
resize/position several times this way. And every time the new bounds
are sent to the winapi.

For theme support you need "bottom up" too:
For example a Control with Align=alBottom is anchored to the left and
right, so its width is defined by its Parent. When 
Parent.AutoSize is true it should resize itself according to its
children. Now you have a circle dependency. 
The bottom up part is done in the LCL with the CalculatePreferredSize.
This was already done with the old autosizing code. It also used the
random walk approach.

The random walk has (at least) three disadvantages:
1. it is random. A control can resize several times. This is especially
true for the LCL, because it has more autosize properties than
the VCL, has additionally bottom up, runs on different widgetsets
with different order of WMSize messages. This makes this "stable"
algorithm go nuts and causes a lot of flickering.
2. it is not sufficient for bottom up. Only checking the parent and
sibling is not enough if you have a two level dependency. For example a
label in a groupbox in a notebook.
3. It does not work well with some special phases. For example
when a form is set to visible, all handles must be created and turned
visible. Creating a handle means applying all properties to the handle -
a lot of changes. This starts the random walk many times - more
flickering.

 
> I'd accept a two-pass resize, with the determination of the min/max 
> sizes in the first pass, and the distribution of available space in the 
> second pass.
> 
> How does the new autosize work?

There were several changes:
- the update is now done for the whole form, allowing arbitrary
  nesting levels. With the random walk approach this would cause more
  flickering.
- the autosize now uses a two-pass resize with the determination of the
  preferred sizes in the first pass, and the distribution of available
  space in the second pass. Because of OnResizes, overrides and non
  linear dependencies this might need some repeats.
- the changes are not immediately sent to the widgetset, but collected
  and sent after all the computation.
- to further reduce flickering the visible flags are delayed until the
  handles are created and all bounds have been computed.
- you can now delay autosizing and visibility for the whole form. This
  is important for docking were you have to work with arbitrary forms. 
- as side effect many workarounds of the old autosize code to reduce the
  random walk problems are no longer needed and were removed.
- with the removal of the workarounds it is now possible to think about
  custom layout managers that can be written without being an LCL
  expert.


Mattias