You say things much more succinctly and clearly than do I, Lahav. I agree. — Chris
> On Apr 30, 2020, at 3:43 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > OK, based on this design, we are back to using variables (or dynamic > variables) for data entry of anything that needs any kind of processing done > to it after an entry, having to load the values to these data entry objects > when loading the form, and copying the values back when we want to save any > user changes. > > OR > > We can use the Form.XXX notation to gain the advantage of that new nifty > option, but lose the generic coding ability. > > I'd say it's a choice, but the lack of the ability to address an object from > within generically definitely seems to be a glaring omission... > > Lahav > > -----Original Message----- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via > 4D_Tech > Sent: Thursday, April 30, 2020 3:20 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Keisuke Miyako <keisuke.miy...@4d.com> > Subject: Re: Object notation replacement for use of Self in a script — v18 > > I can only share how I would design my user interface, but in short, I would > not have this problem > >> (Object get name).prettyFormat() > > and here's why. > > I see that the form object should either be bound to (=managed automatically > by 4D) or divorced from (managed by me) its data source. > > the object name is only interesting to me for visibility, enable/disable, etc. > I would have some kind of naming convention to take advantage of the @ > wildcard, but that's all. > > as for the data source, if I wanted to implement some kind of rule on it, I > would do so without the form object. > > in other words, I would only use object notation on form objects that do not > need to use form events. > in my opinion, any form object that do use a form event should not have > object notation as their data source, since the event is attached to the form > object and not the data source object. > there would be room for programming error if the same data source could be > manipulated outside the form event. > > same with the current item/position/selection property of the collection type > listbox. > the properties only make sense in the context of zero-coding. > if I want to manage the binding by code, I would keep these properties empty. > > classes are coming in 18 R3, but you can already create pseudo-classes by > writing custom constructors that return an object with prefab properties and > methods. > > until the use of "This" is extended to text inputs and other form objects, I > would not expose object notation (which implies that the target is an object) > in any of my form objects, other than for form objects that exist purely for > display purposes. > > I would focus my use of object notation to areas where classic code could not > go, not spaces already occupied by classic code. > >> On May 1, 2020, at 4:54, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> >> wrote: >> (Object get name).prettyFormat How would that be achieved? > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
