So, instead of printing all products that belong to a certain Category underneath the category name, you can now have the Categories picture on the left hand side and all products for that category on the right hand side. A screenshot’s worth a thousand words:
Inserting such a table is straight forward – you just add a new table column as usual and choose “Table” as column type:
The following dialogs are exactly the same as for a “normal” table – you choose the data source and fields to display. What you end up with is a new table column:
If you select the table, you can edit the table object’s properties. A double click takes you to the usual table content dialog. The nested table is a first class citizen in the Designer. Resizing columns via Drag & Drop is fully supported, drag & drop of fields just works and even the context selection and editing of table cells works flawlessly.
And it doesn’t stop there – a table in a table cell can contain a sub table, i.e. underneath the single products you could include the order details for the product:
Which gives you the result:
Due to the complex nature of the feature, it can only be used in the new databinding mode we’ve introduced in LL20. Thus, usage is currently restricted to .NET applications that use databinding via a DataProvider.
3 Comments on “Support for Nested Tables”
Please provide a way to use this feature for the old data binding mode. e.g. via callback.
Or provide a way to repeat “verankerte” sub-datalines to avoid definitions like this:
LlDefineField(hJob, “colB.00”, B.GetNumrows()> 0 ? B[ 0] : “”);
LlDefineField(hJob, “colB.01”, B.GetNumrows()> 1 ? B[ 1] : “”);
LlDefineField(hJob, “colB.02”, B.GetNumrows()> 2 ? B[ 2] : “”);
Anton, Thanks for your post. I would have loved to add this feature to the “normal” interface, however we need to be able to keep _two_ database cursors at a time (the “main” one and the “child” one) and also need to be able to move both forward independently in case of a page wrap. This can only be done in the new mode, unfortunately. We’ll work on making the required interfaces accessible from other languages as well. C++ would be quite easy, Delphi should be managable, however languages like Xbase++ are very tricky when it comes to COM-like interfaces. Your request has been well received anyway, let’s see what develops ;).
Jochen, thanks a lot for your answer.