Anchoring controls with different parents

[darknatter]

It appears that when I try to anchor together two controls with different parents LCL silently sets position to 0,0 and does not complain.

Firstly, if such anchoring is not possible it should either leave the control alone or raise an error. The current behaviour makes no sense.

If anchoring across different parents is possible I would be grateful to know how to make it work.

Here is what I am trying to do. I am open to suggestions for a better way to do it.

I am displaying multiple records of data from a database table. Nothing is known at compile time. The controls are all generated at runtime. I am not using a grid. The data may be tabulated either horizontally or vertically, and either fixed width scrollable or wrapped, depending on configuration.

Each field has a captioned header, which I want to stay visible even when the tabulated data is being scrolled. I will describe the situation where the data is tabulated with fields stretching horizontally, and records vertically, but in practice I want it to work for both.

My current approach is to do as follows:

Two nested scrollboxes. The outer scrollbox contains the headers above the inner scrollbox, the inner scrollbox contains the data. The outer scrollbox has only a horizontal scrollbar, the inner scrollbox has only a vertical scrollbar. This way when the tabulated data is larger than the window in both directions, scrolling horizontally moves both the data and the headers (keeping them aligned), while scrolling vertically scrolls only the data controls (keeping the headers visible).

I want to align the headers with the data columns. If necessary I can calculate this manually in event handlers, but it would be better to delegate the work to the library. But for this to work it needs to allow me to anchor the header captions (parent=outerscrollbox) to the corresponding data controls (parent=innerscrollbox).

Any suggestions gratefully received.

[Martin_fr]

Anchoring to controls with a different parent is indeed not supported. I haven't looked into what error handling there is or is not. If there is not, then maybe report it as a bug.

I don't have a better idea, than to manually sync the sizes.

Well, or manually scroll, then they can be all in the same parent. But it will likely end up more work (with clipping and all). Depends if you do "smooth scroll". If not, you can reuse the same controls to display different data. Especially if you use wincontrol descendants, this may be of interest, because if you have millions of rows of data, you do not want to crease e.g. a million panels => that will crash your app running out of resources. (labels aren't are problem, they aren't wincontrols)

[jamie]

I know u said no grids howerver, the TDrawGrid is what u want with two outboard scroll bars.

You can sit whole batch within a single scrollbox when things get small.

Wirh the drawgrid you need to paint the cells and there for you can maintain an offset from
Your database. The two sand alone scrollbars can select the offset.

By doing this you need to account for the number of fields visible.

Cells can have variable height and width

Like i said you need to do the drawing yourself so you have full control

[darknatter]

Here is a summary so far:

I want to display tabulated data either horizontally or vertically, optionally with a single record wrapping to fit in the screen, with field headers aligned to their respective fields that remain visible when scrolling records (typically a vertical scroll), and scroll with the fields when scrolling fields (typically a horizontal scroll).

A DrawGrid allows fixed header fields that do not scroll, both for rows and for columns (great).
A DrawGrid does not allow wrapping records (bummer).
When wrapping I want the option of labeling the fields and then not using headers and not aligning fields from different records. This is by definition not possible with a grid (big problem).
I could use a grid when I want headers and not use one when I want wrap, but this would require two independent implementations, because they would work differently, and would not allow headers and wrap at the same time. (not practical)

A DrawGrid does add other handy stuff, like allowing the user to resize or reorder the columns/rows and click on the header to sort. But for now the most efficient solution for the current task looks to be retaining my current implementation and manually handle the header positioning, including window resize events. There will be other functionality where a DrawGrid will be a perfect fit.

Thank you to everybody who made suggestions.

[jamie]

I guess it depends who is behind the wheel.

Have a good rest of the year and enjoy your solution.

Jamie.