Indeed, if you are using a process or an IP variables to hold the entity (or object for that matter), you will get a pointer to that variable. But if you are using the Form.XXX notation and eliminate the use of process or IP variables, the pointer always return Nil, so it's useless.
The question remains, what is the right "New World" approach to achieve functionality that seems to have no work around. Lahav -----Original Message----- From: 4D_Tech <[email protected]> On Behalf Of kculotta via 4D_Tech Sent: Thursday, April 30, 2020 3:03 PM To: 4D iNug Technical <[email protected]> Cc: kculotta <[email protected]> Subject: Re: Object notation replacement for use of Self in a script — v18 Sorry, meant to say the pointer that results from the Object Get name is to the entity > On Apr 30, 2020, at 3:59 PM, kculotta via 4D_Tech <[email protected]> > wrote: > > 18.1 > > The pointer OBJECT Get name(Object current) is to the entity instead of the > to the entity attribute. > > The field is eg, MyEntity.MyName, but the pointer to the form object > ends up being ->MyEntity > >> On Apr 30, 2020, at 3:52 PM, lists via 4D_Tech <[email protected]> wrote: >> >> Sorry, Are you saying that you can get a valid pointer with Object get >> pointer() on a dot notation object of a form?, if so what version? >> >> Lahav >> >> -----Original Message----- >> From: 4D_Tech <[email protected]> On Behalf Of kculotta >> via 4D_Tech >> Sent: Thursday, April 30, 2020 2:50 PM >> To: 4D iNug Technical <[email protected]> >> Cc: kculotta <[email protected]> >> Subject: Re: Object notation replacement for use of Self in a script >> — v18 >> >> Yes, I'm using it, but it really seems like an artificial way to get an >> entity field's displayed contents. >> >> I'll explore your example. >> >> Keith - CDI >> >>> On Apr 30, 2020, at 3:45 PM, lists via 4D_Tech <[email protected]> wrote: >>> >>> Did you actually test this?, any kind of a get pointer on a form object >>> having a dot notation source will return a Nil pointer, regardless of the >>> name matching or not. >>> >>> If you are using matched names, you could use the following: >>> >>> Form[Object get name(object current)]:=DoWhatever(Form[Object get >>> name(object current)]) >>> >>> But that is not quite what we need to be truly generic.... >>> >>> Lahav >>> >>> -----Original Message----- >>> From: 4D_Tech <[email protected]> On Behalf Of kculotta >>> via 4D_Tech >>> Sent: Thursday, April 30, 2020 2:29 PM >>> To: 4D iNug Technical <[email protected]> >>> Cc: kculotta <[email protected]> >>> Subject: Re: Object notation replacement for use of Self in a script >>> — >>> v18 >>> >>> 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 >>>> <[email protected]> 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 >>>>> <[email protected]> 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 >>>>>> <[email protected]> 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:[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] ********************************************************************** ********************************************************************** 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] **********************************************************************
