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 <
4d_tech@lists.4d.com> 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 <4d_tech@lists.4d.com>
> 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 <
> > 4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
> >> **********************************************************************
> >
> >
> >
> > --
> > 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: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
> **********************************************************************



-- 
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:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to