Sorry, no example to upload. I’m using a similar scenario, just in a more complex solution, so difficult to extract.
Imagine a form, left side a large listbox, showing all records.
Left side a subform, showing details of the selected record.
The user can change the displayed table (customer, invoice, products, etc), which dynamically update the listbox on the left.
To have correct display of the details, the right area with the details is a subform, so I can assign different input forms, via:
OBJECT SET SUBFORM(;“Direkteingabe”;[Kunden];“Orda_Kunden1”)
OBJECT SET SUBFORM(;“Direkteingabe”;[Auftrage];“Orda_Auftrag”)
OBJECT SET SUBFORM(*;“Direkteingabe”;[Rechnungen];“Orda_Rechnung”)
Some detail form, such as Kunden/Customer, have several pages. Instead of switching pages I have many forms (Kunden1, Kunden2, Kunden3), where I simply assign another form to the subform instead of switching pages.
In the main form I’m using the Form object for many data, like displayed table (.table), title of the window (5 of 200 products), and more.
Form.SelectedElement is automatically managed by the list box.
Form.Direkt (sorry for the strange attribute name, not even makes much sense in German, needs refactoring, keeping here the name to allow me copy&paste) is assigned to the subform and stores all information needed to display the details.
It is an object itself, with deeper attributes.
Form.Direkt.DSatz is the current selected entityy.
Object Method of the list box (extract).
: (Form event=On Selection Change)
$status:=Form.Direkt.DSatz.save(dk auto merge)
// all is fine
: ($status.status=dk status automerge failed)
ALERT(“somebody else has changed the same fields, your modifications cannot be saved!”)
: ($status.status=dk status locked)
CONFIRM("record locked from "+$user;“wait”;“cancel”)
EXECUTE METHOD IN SUBFORM(“Direkteingabe”;“Orda_Listbox_subformMethod”)
When the current selected record changes, I’m checking if there are modifications needed to be saved - and handling record locking/collisions as well.
If all is fine, I assign the new entity.
Finally I execute a method inside the context of the subform, to update the details.
For all tables this is doing something as:
depending of the table, more fields are set, Popups are filled, objects are enabled/disabled, etc.
Form.Customer.Name or Form.Invoice.Date is easier to read in the form or form method as a generic name, that’s why I assign that. Remember, that’s not a copy, no memory wasted, just a reference…
Note that in the subform, there is another Form object (of the subform, not of the main form)
In the main form I have assigned Form.Direkt
The Subform receives its own Form object with the content of the main form’s Form.Direct attribute.
The form (assigned to the subform) is using variables to display the data via Form.Kunde.name ([Kunde]name)
Now back to the start. When user changes the selection of the list box (click on another line), I check if data was changed, needs to be saved, then assign the new selected line, call the subform, which assign it to my attribute, which triggers are redraw…
Sounds more complicated as it is. But works (surprisingly) simple and allows an user interface design not possible before…
It was not created for demo/training purposes, I wrote the code when learning ORDA.
And yes, attribute names do not follow best practice.
The database/structure is 30+ years old, I would use very different naming and coding style if I could redevelop from scratch.