Jeremy, You know objects are not intended as a way to manage transferring pointers around. The docs actually refer to a more limited use of pointers in objects: https://doc.4d.com/4Dv17R4/4D/17-R4/Data-Types.300-4054923.en.html
A property value can be of the following type: ... pointer (stored as such, evaluated using the JSON Stringify command or when copying), If you look at the object in the debugger you see a pointer is stored as a text ref and 4D dereferences it when used either by Stringify or when you use OB COPY. This makes it handy but I think it's good to keep in mind the intent of the object is to let you manipulate the value of the pointed to element and not move the pointer itself around. Also, objects are managing references to the data which is similar to what a pointer is doing. You don't really need to use a pointer in an object to reference the original data. This is why, I think, the documented use case for pointers in objects is limited to a way to put data into the object. The fact 4D tolerates pointers in objects used other ways may be as much a problem as a benefit precisely because it allows us to keep using them in this way. I am a big fan of object notation and the ORDA commands but there are places I avoid using them. I think using a classic 4D approach to handling pointers, for instance, is more reliable. And if this is a case of trying to retro-fit some ORDA code into existing code I have rarely found this productive. You spend so much time making the old variables and _pointers_ consistent with ORDA and then moving them back again there's just no benefit. ORDA commands work best in an ORDA context. Frankly I rarely use pointers for anything in a v17 database. Objects and Form are just easier and more robust. What I have found productive working with old code is to start with a new method and attempt whatever the overall goal is using all ORDA commands and variables. After I did this a few times, and became familiar with the flow of ORDA code, I usually have a method, or set of methods, that's about 1/3 the size of the original. Speed depends on the number and type of lookups. On Mon, Feb 25, 2019 at 11:18 PM Jeremy Roussak via 4D_Tech < [email protected]> wrote: > Kirk, > > My apologies. I mistyped the offending lines! > > The lines causing the error dereference the pointers. So they are > > $to.toDate->:=$from.toDate-> > $to.toAge->:=$from.toAge-> > etc. > > The curious things are that (a) the dereferenced pointers do definitely > point at variables of the same type; (b) although I get an alert with the > error message, the assignment does in fact work (that is, if I click > “continue”, everything is exactly as it should be when the method > completes). > > I can get round the error by using pointer variables: > > $pTo:=$to.toDate > $pFrom:=$from.toDate > $pTo->:=$pFrom-> > > which works fine. I just don’t understand the actual error message, since > I’m not doing what it’s accusing me of doing. > > Jeremy > > > > > On 25 Feb 2019, at 16:47, Kirk Brooks via 4D_Tech <[email protected]> > wrote: > > > > Jeremy, > > Since you are writing the data to an object what's the value of using the > > pointer? Why not just write the data? > > > > In fact, since TCMGetRow looks like it is simply holding the data for the > > transfer you could make it a loop: > > > > For($i;1;number of objects) > > > > $o["_"+string($i)]:=Object get pointer(Object named;$root+string($i))-> > > > > End for > > > > This way you don't need to care about the data type assuming the 2 > objects > > actually have the same typed objects for each index. > > > > But to specifically answer your question I would take a look at the way > the > > date value is stored in your object and then how you reference it. > There's > > another post about dates and objects that sounds on point with what you > are > > doing. > > > > > > On Mon, Feb 25, 2019 at 7:37 AM Jeremy Roussak via 4D_Tech < > > [email protected]> wrote: > > > >> I have a form which shows a variable number of rows of numbers and text. > >> The rows are created using OBJECT DUPLICATE on each of the half-dozen > items > >> in the row (yes, using a collection listbox might be a better way do to > it, > >> but I wrote this code a while ago). If a row is deleted, I need to copy > the > >> contents of the rows beneath it upwards. > >> > >> > >> So I have a method which creates an object and populates it with > pointers > >> to the created variables. I call this to get a set of pointers to one > row, > >> then again to get a set to the next row, and then I copy. > >> > >> I start > >> > >> C_OBJECT($from;$to) > >> $from:=TCMGetRow($start) > >> > >> then in a loop, > >> > >> $to:=$from > >> $from:=TCMGetRow($i) > >> > >> $to.toDate:=$from.toDate > >> $to.toAge:=$from.toAge > >> etc. > >> > >> > >> > >> TCMGetRow has > >> > >> C_OBJECT($0;$o) > >> C_LONGINT($1;$row) > >> $row:=$1 > >> > >> C_TEXT($root) > >> > >> $root:="vr"+String($row)+"c" > >> $o:=New object > >> > >> $o.toDate:=OBJECT Get pointer(Object named;$root+"0") > >> $o.toAge:=OBJECT Get pointer(Object named;$root+"1") > >> etc > >> > >> $0:=$o > >> > >> I’m getting the message in the subject line in the main loop for each > >> assignment, but only when compiled; interpreted, it works fine. In the > >> debugger, the pointers in $to and $from point to variables of the same > type. > >> > >> I’m quite new to extensive use of objects. What am I missing? > >> > >> Jeremy > >> > >> ********************************************************************** > >> 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] > ********************************************************************** -- 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] **********************************************************************
