I know ORDA ORDA ORDA (think the Brady Bunch marsha...) :) While I am not yet on a version which supports these concepts - it sounds like MORE work to try to force the listbox displaying the child or children (multiple relaters) to be ORDA then to use a 'standard' selection based listbox and simply add to the child table as the user desires. (usually a double click on empty line, or "+" button). Do this inside a transaction and there is no need for code to manage what was there before the user starts to edit the parent vs what is there (or not) after the user completes editing (accept or cancel) the parent record.... excuse me entity.
under your proposed ORDA implementation You will still need to manage all the validation(s) your child record needs + all the overhead you are adding to massage the listbox to do things the "ORDA way". This seems like a lot of work for very little gain. I would think this is doubly true if you already have code to manage a listbox which handles child records. My 2 cents Chip On Thu, 29 Aug 2019 14:39:46 -0600, Chris Belanger via 4D_Tech wrote: > 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] > ********************************************************************** --------------- Gas is for washing parts Alcohol is for drinkin' Nitromethane is for racing ********************************************************************** 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] **********************************************************************
