Thanks for taking the time to reply, Kirk. I share your enthusiasm for v17. I may not have phrased my question very well.
Listboxes are capable of editing records ‘live’ very well. However, the problem is when you want to operate on a NEW record. It is much more natural to a user if the listbox has some ‘blank lines’ that they can enter into and the program just manages the linkage itself. When I used to use ALP years ago, I used to ‘copy’ the data from the related selection to arrays, and then update the related data as required after ‘OK’. I was hoping that it would be simpler using list boxes and entity selections. I could conceivably ‘copy’ the related data to a collection, add blank lines to the collection, and then update the related data as needed. But that requires more management on my end. Yet to show the related data in a listbox (i.e. ‘invoice lines’) as an entity selection, the problem is how do you give ‘blank lines.’ The choice seems to be to create some ‘previsionary’ records and add them to the es_selection you are operating on. I suppose that is a possibility. Then a person just needs to ‘link up’ records that ‘really’ belong and ignore the rest. ———— PLAN OF IMPLEMENTATION As I type this, I just came up with an idea that I could still: • operate on the ‘related data’ in an entity selection (not a collection) and • still facilitate the ability to ‘add’ a blank record to the bottom as needed. • I can respond to user actions that would ’suggest’ they want to add a new line to the detail. (such as if they click ‘below last entity in the entity selection; table after last column of last entity in the entity selection). • if they do indicate that they want a new one, I can .add() a record to the table, append to bottom of the entity selection, and also add it to a ’new’ entity selection so I know what ones to confirm afterwards. * When they ’save’ the main record, I can go through the ’new’ selection of detail and discard (drop) any invalid detail records. So I would manage this with: es_invoiceDetail — the listBox would use this as its entity selection. es_newInvoiceDetail — an entity selection of the prospective ’new’ records that get added in response to user actions If a user does an action in the listbox that would ’suggest’ they want a new record, I can create the new entity, append it to the bottom of es_invoiceDetail, and also add that same entity to es_newInvoiceDetail so it can be examined when the editing is accepted or rejected. SAVE: examine the es_newInvoiceDetail; ‘link up’ any that should be ’saved’ and delete any that were ‘blank’ or invalid. These can also be removed from es_invoiceDetail if I wish; and then I could do any calculations based on that es as needed. ———— Does this approach seem like a good one to leverage the ability for listBoxes to use entitySelections, and yet enable the natural ‘add line’ that a user would be expecting, and at the same time ensuring that a bunch of garbage lines do not get created and saved in the process? — Chris > On Aug 26, 2019, at 7:29 PM, Kirk Brooks via 4D_Tech <[email protected]> > wrote: > > Chris, > Working with collection or entity selection based listboxes is easier for > me when I think of the listbox as simply 'showing' or 'displaying' the > underlying data. From this perspective when I add something to that > underlying data the listbox updates itself because that's all it's doing - > showing the data. > > Old school listboxes, in contrast, were objects that did the modifying of > the underlying data. So I had to change the listbox to change that data. > See how it's sort of flipped? > > In the example you mention you probably have a button or something to > initiate adding a new line. That's where the new data object (whether it's > a record or an object in the collection) get's created. The listbox will > change to show it. > > I've been using 17r6 which is pretty darn good with this stuff. In some > earlier versions if you changed the data outside of the listbox object > itself, I think, and you were using Form you had to set the collection to > itself to update the listbox. So if I had Form.myCollection displayed in a > listbox and it was updated by some other action I would want to be sure to > call > > Form.myCollection:=Form.myCollection > > Like I say this has been fixed but I don't remember where. > > On Mon, Aug 26, 2019 at 5:31 PM Chris Belanger via 4D_Tech < > [email protected]> wrote: > >> I am using ORDA-based programming exclusively now; not using ‘classic’ >> methodology. >> I am wondering what you are doing about creating ‘new’ entities within a >> listBox (related to some master record). >> >> For example, classic scenario: >> INVOICE - invoice table >> INVDETAIL - invoice detail lines table >> Invoice opened; INVDETAIL displayed in a listBox. >> >> User needs to add invoice lines; BUT an ‘ADD BUTTON’ is clumsy, and still >> could result in erroneously-created BLANK entities in the INVDETAIL file. >> >> Using a COLLECTION-based listBox makes it easy to let them do whatever >> (can create ‘blank’ entries in the collection so they can naturally enter >> within the listBox) and then ’save’ these lines to InvDetail when they save >> the invoice. >> But that means managing the underlying InvDetail records. >> >> So is there a better way? Do Transactions work with ORDA? >> >> Thanks for any input. >> >> — Chris >> ********************************************************************** >> 4D Internet Users Group (4D iNUG) >> Archive: http://lists.4d.com/archives.html >> Options: https://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:[email protected] >> ********************************************************************** > > > > -- > Kirk Brooks > San Francisco, CA > ======================= > > What can be said, can be said clearly, > and what you can’t say, you should shut up about > > *Wittgenstein and the Computer * > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
