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 <[email protected]> On Behalf Of Keisuke Miyako via 4D_Tech Sent: Thursday, April 30, 2020 3:20 PM To: 4D iNug Technical <[email protected]> Cc: Keisuke Miyako <[email protected]> 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 <[email protected]> > 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:[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] **********************************************************************
