Parent/Child forms and ORDA

I’m starting to explore moving my forms to the new ORDA Entity style of managing them, however, I’ve run into a bit of a roadblock when it comes to Parent/Child forms with a complicated UI in the children section. From what I can see there’s nothing to support Related Entities on a Form other than a Listbox. There doesn’t seem to be any way to use a List Subform with the Related Entities.

For example, Invoice Lines on my Invoice form have far too complicated a UI to fit into a Listbox, and List Subforms are a no go.

How are others handling this?

Here’s an example of my Invoice form that I’m trying to refactor to ORDA.

[]32395446;“Your comment here…”[/]

I think you can’t do such complicated row without a child form :frowning:
Have you look on 4D View Pro (Object listbox ?) but this is not ORDA.
A simple ORDA listbox + a child form beside :?:

Hi Peter,

Very nice form.

I think Manuel is correct if you want to try to duplicate this interface - you probably need either Write Pro or View Pro or both if maintaining this exact design is required.

But is the exact design actually required? A technique I use when I have complex records I want to present in a list is to populate a listbox with key data and populate a subform with record data when the user clicks. From your example I’d try something like the diagram.

[]32402931;“Proposed new form…”[/]

To do this in an ORDA-ly way I’d use Form and I’d set it up the parent Form something like this:
{
Form.inv_obj
Form.line_items // reference to the line item entity selection
Form.listbox_items // empty collection to start
Form.selected_item_index // listbox data source selected item number
Form.subform_data // this is Form for the subform
}

I start with a new form when I’m converting. Copy over the nice tool bar and such but only add things you actually need. With ORDA you need a lot less than with classic 4D.

When the user identifies an invoice you query for it and put the reference in Form.inv_obj.

Setting Form.line_items to the entity selection of the line items makes it easier to work with here on the form. Depending on how complex that selection is you may want to just query for them directly or reference it in the entity object.

The invoice fields are easy to identify: [Invoice]Date_Due, for instance is Form.inv_obj.Date_Due. And so on.

The listbox is where things get interesting. To match the display you have now we can’t just put drop the entity selection into it. But you can create a display collection that you drop into it. Basically you need to create a display object for each line item. This object is going to be what we display on a line in the listbox. Something like:
{
“type”: “GL Code”,
“description”: “line one\rline2”,
“amount”:“12345.00”,
… // and so on
}

A method called “Entity_selection_to_text_collection” could take the entity selection as $1 and return a collection of these objects which you then display in the listbox. So:
<code 4D>
Form.listbox_items:=Entity_selection_to_text_collection(Form.line_items)
</code 4D>

is all you need to make the display collection. You could dress this up by using styled text.

When the user clicks on one of these lines you put a reference to the selected line item into the subform’s Form object:
<code 4D>
Form.subform_data:=Form.listbox_items[Form.selected_item_index]
</code 4D>

About the subform: the subform object on the parent form should be set to Object type and its ‘Variable or expression’ set to Form.subform_data. When you setup the subform this way it makes it easy to manage the contents of the subform’s Form object by simply setting Form.subform_data. You could also accomplish this by getting a pointer to the subform object like so:
<code 4D>
Object get pointer(Object named;“subform”)->:=Form.line_items[Form.selected_item_index]
</code 4D>

But why? With ORDA I rarely need pointers to form objects. Rarely.

“What about updating the displayed fields?” I see you’ve got a popup menu for the date fields. In classic 4D we would modify the field or variable on the form to change the record. With ORDA you change the entity and the input object updates itself. So in classic 4D you might do:
<code 4D>
Object get pointer(Object named;“dataDue_input”)->:=DateWidget
</code 4D>
with ORDA I would do:
<code 4D>
Form.inv_obj.Date_Due:=DateWidget
</code 4D>

Now you can design the subform to manage the specifics of data entry. Since you have a reference to the line item entity in Form you can refer to the entity properties directly. So the Item description input would be Form.description (assuming [Line_Item]description).

The great thing about using references in this situation is the changes made in the subform directly change the entity record you loaded initially. You need to explicitly save those changes at some point.

This post is running a little long which may suggest what I’m describing is really complicated. It’s not complicated but it’s really different from the way classic 4D works. It’s a different way of looking at the tasks because you are working with a different set of tools.

Thanks for the replies.

Kirk, you have given me a lot to think about. I’ve thought about the idea of having the Invoice Line input area out side the list of Lines. It certainly would make my life easier, but would probably not be a great solution for the customer. They’ve been able to enter Lines inline for years now, and this would be a step backwards for them. They process 4,000 - 5,000 invoices a month, so this interface needs to be super slick.

4D Write and View are ideas worth exploring. I’ve also thought about SVG and Web Area.

I for see a lot of R&D in my future. :-?