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.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”,
… // 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:
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:
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:
Object get pointer(Object named;“subform”)->:=Form.line_items[Form.selected_item_index]
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:
Object get pointer(Object named;“dataDue_input”)->:=DateWidget
with ORDA I would do:
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.