On Fri, 23 Apr 2010 20:06:29 +0200 Hans-Peter Diettrich <[email protected]> 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
