Feedback for replacement of former output list with listbox collection

I’m considering to replace our good old output lists with listboxes collection.

Did someone face any issue in a such condition?

4D v18.1

Thanx

If the times it takes is an “issue”, yes. Not if you consider like me using output lists is bad for the future (and the present).

I remember I had some code to read the output list at runtime (FORM LOAD, maybe) and convert what could be converted in xml describing the listbox - now I’d use json. It’s a part of the job only (you’ll have to adapt form method, objects methods, fields and variables have not the same scope, etc). I suppose more can be “automated” now with recent tools from Design Object Access theme.

Listbox collection ? Why not a listbox entity selection ?

: Eric TROTTA

Listbox collection ? Why not a listbox entity selection ?
Maybe. That was my 2nd thought.

The database is old and tricky and (for the moment) I’ve no idea what a listbox entity will envolve.

BTW what could be the advantages or inconvenients in using collection or entity LB

I switched the output listbox to Entity selection after trying Collection. Much more convenient.
One problem, adding an entity to the “selected items” entity selection does not highlight it in the listbox the way adding a record to the “highlight set” highlights it in the listbox. LISTBOX SELECT ROW must be used.

Double clicking an entity to edit it in the input form, when the input form uses entity attributes instead of fields.
The automatic navigation buttons seem designed to only work with a “classic” selection. Saving and loading the next, previous,… records must be done explicitly.

Unless something has changed recently.

I am building a solution to customize a single listbox for displaying any list from collection or entity selection.
List description is stored in objects.

: Keith CULOTTA

Double clicking an entity to edit it in the input form, when the
input form uses entity attributes instead of fields.
The automatic navigation buttons seem designed to only work with a
“classic” selection. Saving and loading the next, previous,…
records must be done explicitly.

I replaced a record selection listbox with an entity selection listbox to get the improved search features and flexible configuration without the hell of automatic relations. Changing the input forms to use objects will be too much work and a waste of time. All you really need to do is control the double click event and make sure you create an equivalent record selection to whatever the entity selection is. Adding records also requires some adjustment. But in the end you can get the advantage of collection/entity selection list boxes without rewriting all your record based forms.

I considered also to replace output forms with list boxes - the biggest disadvantage I see is the limitation to display only one line per record. Sometimes it is convenient to show information for one record on more than one line and not to add endless columns for display. e.g. showing an invoice may consists of:
Number, Amount, Customer, Date and displayed smaller text in the next line (Full name, address, amount due,…) Sure you can do it in some way with styled text…

: Reinhard PESCHORN

I see is the limitation to display only one line per record.

Hallo,

You can do it if the column is a formula:

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

I mean it in this way (see picture). or - sometimes you also want to have one line in full width and the next splitted in 3 column.

[]34635573;“Sample…”[/]

For complex displays, you could use a HTML table in a web area ?
But it would be more complicated to interact with the web area…

There’s also styled text or SVG.

Yes - we can use HTML, SVG and Styled Text - but it will take much longer development time (my personal experience) than using the good (old) form editor. If in the future ORDA gets an “subform” feature with an editor - this would be nice and speed up development. At least 4D is/should be a 4GL IDE and not a plain programming language.

This behaviour could be address with subforms.
Sample here: https://github.com/vdelachaux/4DPop-XLIFF-Pro/blob/master/assets/all.png
Another one is the 4D for iOS editor that is only done with subforms.

Really nice done and designed at the technical border of the language. But also really a lot of code to get this work. Duplication seems only an option for a small selection.
Imaging how simple it could be if we can assign an entity selection to a subform and use the existing events?

Reinhard,
First, nice form. Thanks for reminding me that old-school subforms can
still be useful.

Second:

: Reinhard PESCHORN

Imaging how simple it could be if we can assign an entity selection
to a subform and use the existing events?

If I understand your comment you can do that. Make the subform (the object on the parent form) an object type. When you do this the subform’s Form is that object. This isn’t exactly what you suggested - that the subform be a collection but this is actually more powerful, I think. You can set an entity as the subform object and the form is basically and input form for the selected record. Particularly useful if working with an entity selection based list box on the parent form - you can put the current item of the list box into the subform object and provide on the fly editing of the record in the input form.

This is also a great solution for tool pallets - the subform object makes whatever choices are made directly available to the parent form. If you set it up correctly this solves the problem of nested subforms communicating with the top level parent form.

You can even set the subform object to the parent Form - in which case the subform becomes the equivalent of another ‘page’ of the parent form.

Kirk,

thanks for the suggestions. The form sample is taken from the current MS updater App. (I can’t take credit for it. - but I liked the style too. :slight_smile: )

I will try the new approach. Maybe we will get a collection type or entity collection for the subform…

Reinhard,

: Reinhard PESCHORN

Maybe we will get a collection type or entity collection for the
subform…

Hmm. I don’t think it’s possible. Form is a function that returns an object, if I recall correctly from some other discussions around here. So that pretty much kills it right there. Or at least the ability to use Form in the subform to refer to that collection.

An entity selection is an object, however. So you have that option now. But this is really limits our options. Let’s say I want to display this entity selection in a list box on the subform. On one hand it’s very easy to setup: the list box data source is Form and the particular columns I want are This.. That’s cool. But since Form is defined as the entity selection I can’t use it for anything else having to do with the list box or the subform at all. Including things like the list box selected entity and so forth.

And I can’t use it for a collection at all.

But if I have the entity selection (or collection) in an object named ‘data’ I have much more freedom. And the only change on the list box itself is the datasource is now Form.data.

But for discussion what would be a use case where having the subform as a collection gives you something you need?

Thank you Kirk,

you are right. I will test it on real case and get more inspiration from the samples, KB and documentation.

KR Reinhard