Amidst the spirited discussion about dots in form object names is a post about multiple entity selection or collection list boxes on a form. I thought I’d share an idea I’ve been working with that is showing promise dealing with these.
My goal is a consistent naming convention. The list boxes are very cool in terms of the selected items, position and current item properties (or data sources) but naming these things can get confusing quickly. And there’s the question of the form object name (the list box widget on the form). I think using dots is a bad idea for form object, BTW. So what’s better?
First I adopted a few rules:
- The form object name will end with “_LB”
- I’ll create a Form object with that name for each list box
- This object will have 4 properties:
In practice it looks like this:
A very simple method makes set up easy:
// LB_init_obj () // ------------------ // Purpose: init a listbox object on Form C_OBJECT ( $0 ) $0:= New object (\ "data"; Null;\ "curItem"; Null;\ "pos";0;\ "selected"; Null)
which in practice looks like:
Case of : ($form_event=On Load) Form.docs_LB:=LB_init_obj ... End case
Now I have a consistent naming convention. When I know the name of the listbox form object I know the name of all the important parts. Since all those parts are in an object I can write various methods to operate on that object without even knowing the name of the listbox.
The only tradeoff is the fixed name of the data. Here is that same listbox in action:
Clicking on a row on the left selects that record which has a number of related Documents as well as a list of keywords in a data field. So the contents of the Document listbox are:
All that just happens when the row is clicked. If I want to stick with no coding to make this work I have to accept using that non-conforming name. However, it’s very simple to simply assign that reference to my convention in the cells_LB:
Case of : (FORM Event.code=On Selection Change) Form.docs_LB.data:=Form.cells_LB.curItem.docs End case
If you are thinking this approach leads to rapidly increasing the amount of memory used remember that we are working with
references. The memory footprint is very small even when you use these tricks on multiple, large collections or entity selections. And the responsiveness is imperceptible.
To show how nicely this cleans up the listbox issues here’s a debugger screen shot: