>>>>>>>A reference to a pointer still points to the same object.
>>>>>>
>>>>>>Yes. That's what I want. I want a reference to the existing object, so that the object exists, and the reference points to the object that exists as well.
>>>>>>
>>>>>>It's as the second example was setup in my code above. I'm effectively using that method presently, and it works, but it's clunky. I would like to have a way to store a binary object which is the explicit reference to the existing object, so I could reference it without having to use an intermediate variable name which is then set to the object reference itself. I'd like to remove that "middle man" if possible.
>>>>>
>>>>>My dear, I fear this is not possible with VFP. Remember, this is a dinosaur. Even if you figure out the adress of an object. Run time generated stuff like objects and there props might be mixed with vars.(Create a var, create an object, an other var and then a property to the object. The storage of the object must be fragmented somehow.) Stuff you can not store binary like references to other objects
>>>>
>>>>I wonder if that would be possible, to pass the object by reference to a DLL which obtains the address, and returns it as a value, allowing the value to be saved as an integer, and then reconstituted similarly by calling a DLL with the value, which updates another variable passed by reference to then refer to that object?
>>>>
>>>>Hmmm....
>>>
>>>Why not. The structure of a vfp object and the vars must be somehow declared. I hate to say it, but the only person I can imagine that might understand it know is Chen ... The original developers, but that's old knowledge.
>>
>>As vfp is garbage collected with a schema to move/compact memory to get large uninterrupted areas, the whole discussion is somewhat pointless. You have "handles" in vfp, which could be seen as smart pointers, which are informed/updated when the base adress pointed to is moved. Either to some kind of serialization (JSON, XML, stream) or add a searchable structure of handles (or object paths to eval/getpem)
>
>Can you give me a source? Now I'm curious.

Uummph... not directly. But I found descriptions of vfp garbage collector (and sometimes failing) compaction in Calvins blog where he describes gaps in memory maps. There was first an article about memory layout in Dotnet, followed by 2 articles on vfp, one wth some source code I used to identify the situation where memory becomes so sparse that Rushmore is disabled quietly. A naive pointer to a specific memory adress would have great chances of having the rug pulled out under him in any garbage collection fired...

I would have to read up again on the mechanics of accessing strings in C in a fll - there you move from the pointer to vfp memory to raw C pointer. Pretty certain a test scenario could be built, but I am not longing for a return to the C machine room unless bribed with insame amounts (think "Schmeeeerzensgeld")

Also certain that there are probably more more than 2 handful of people with knowledge of those structures: first all the people at MS hacking at the C(++) sources, besides Calvin was Alexey T. who informed me once that one of the bugs I had reported was a wrong type cast in C code, and probably a few others. In Userland besides Chen is Christoph Lange, who knows much more about internal working of vfp compared to me, and most devs creating Flls have some knowledge about vfp variable structures just by reading comments in the sources...