This example does not avoid having to carefully name form objects and the form object must have "matching" variable and object names: variable entity.MyName with its object name of "MyName"
// the object method a_test (OBJECT Get name(Object current)) // a_Test $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] ALERT($s) // the value entered into the text area Keith - CDI > On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a > single process variable, interprocess variable, or any other ‘vestiges’ of 4D > Classic. I am ‘fully committed’ to object notation. I also use Storage > extensively for system-wide values, and really love it. > The problem I describe is that I need a way to generically ‘get’ and ’set’ > the value of an object (meaning an entry variable on the form). > > 1) A variable is placed on the form. It’s “variable or expression” is: > Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of > “enLSDFromRigDispatch” > > I have given it this name because it gives me a simple methodology to > SHOW/HIDE a whole group of objects on the screen with OBJECT SET VISIBLE(*; > “enLSD@“;…) > > Now I wish to use a standard project method to ‘pretty-format’ this variable. > With ‘4D Classic’ this is easily achieved by making a project method that > takes a POINTER in $1. > The OBJECT SCRIPT would be something simple, like: > PRETTY_FORMAT(Self) > [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of the > variable and do any formatting options needed] > > With ‘4D DOT NOTATION’ … > — How do I create a simple OBJECT SCRIPT that would do something similar to > that in 4D Classic? — > I don’t feel that I should have to resort to using the ‘variable or > expression’ name in every single script; because what happens if I change > that variable for some reason and it totally screws up the object script? And > it also makes it very complicated. > THE OBJECT METHOD should be something as simple as: > PRETTY_FORMAT ( Object Get Name ) —— instead of Self > > The PRETTY_FORMAT( ) should be able to get at and set the value of the form > object from that name. > > Alternatively, if one wants to not bother having scripts for every input > variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: > Case of > :( Form event code = on load ) > Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 > ) … // objects that need to be ‘Pretty Formatted' > > : ( Form event code = on losing focus ) > $curObjectName:= Form Event.objectName > … see if is in the list of .col_toPrettyFormat … > PRETTY_FORMAT( $curObjectName ) > > … > > So how would one implement something like: > PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( > Form Event.objectName ) > ??? > > Thanks, > Chris > > p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create > classes. That is very intriguing and a necessary development in 4D, as is > C_VARIANT( ). > If one wanted to be able to have the script be: > > (Object get name).prettyFormat How would that be achieved? > > Even if in the script one could use “This”, but it is null. > I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in > a TRIGGER (referring to the record/entity being operated on), etc. But it is > not, and I have trouble understanding why not. > > > > >> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> my feeling is that generic coding is very much possible in object notation, >> but we need to accept that the approach is different. >> >> if you prefer to use pointers such as "Self", >> I think it's best to avoid object notation, >> at least if your goal is to make the code generic. >> >> it's not a defect of object notation, >> but the way to write generic code is different. >> >> if you want to make your code generic in object notation, >> I think you need to fully commit. >> >> what I mean by that, is that you need to think of objects and classes, >> properties and methods. >> >> basically, instead of >> >> doIt(Self) >> >> you would write >> >> $obj.doIt() >> >> where the doIt() formula works on "This". >> >> in my opinion, to take full advantage of object notation, >> it is pretty much mandatory to use >> >> This >> Signal >> Formula >> Form >> >> extensively, as well as >> >> Storage >> New shared object >> New shared collection >> >> strategically. >> >> simply replacing interprocess/process variables with object notation, >> may semantically look like object based coding, >> but at that level you may be losing major advantages of classic code, >> while not gaining much from what the new way of coding has to offer. >> >>> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech >>> <4d_tech@lists.4d.com> wrote: >>> And v18r3 does not even have a solution to this in its documentation. >> >> ********************************************************************** >> 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 **********************************************************************
