Quote:
|
Marks answer works and I am using it but I can't help but feel like I
|
am missing a "*" or "&" or "ByRef" or "new" or something in the
language that would make my future life in this language easier.
Marks attach is really the key to doing it like this.
I remember long discussions on the newsgroups about
this topice a long time ago. I must be getting old.
What I think you are saying is,
since you have a variable tcTmp,
and that variable is store at a certain memory location,
you want to put/pass the address of that object into an array,
and then be able to use that memory reference/ address
and be able to use that object by passing the address of the object.
Think of a tcursor as a very complex object.
One of the complexities of the tcursor,
is that it knows to close itself when the variable goes out of scope.
Imagine what would happen if you passed the address of the tcursor
somewhere else, and then the tcursor actually closed,
either intentionally by the programmer,
or by pdox / opal / garbage collection(so to speak) when the var went out of
scope.
And then imagine.....you tried to use that address somewhere else down the
road,
or later in your code......
......<insert tragic body shudder here>................
Basically when you pass variable in pdox opal,
when you use the word var,
you are passing it by address.
It does not pass a copy of the var, but a pointer to the var.
This is a sample method declaration, showing the var keyword,
so that object is passsed by reference.
method cmProcessFile(var tc tcursor) logical
For a tcursor, I believe the following to be totally not allowed
method cmProcessFile(tc tcursor) logical
The creators of opal , in their wisdom,
didnt want multiple unmanaged copies of the tcursor being tossed all around.
Tcursors can only be parameters with the var word.
Thats because multiple copies of file pointers can be a dangerous thing.
You might feel that if you shoot yourself in the foot,
you deserve it, but, opal actually will save you from yourself every once in
a while.
Its really the same principle that certain other modern languages
do not like string pointers. Some consider it unsafe to change the middle of
a string.
Instead, you need to make a new string with the modifications.
I dont see the lack of what you are asking for as a limitation,
but as a reasonable precaution against dangerous situations.
If addresses of memory locations were passed around too often,
it would be hard or impossible to automatically close some objects,
by knowing when it goes out of scope.
Its late, so I am not sure if this came out understandable.
Just my .02
.......and glad that Marks advice was able to help you.
Robert Wiltshire