Yes, using an object handle seems not to be the best solution in this
particular case. I was using them since the start of my Rotor project, but
after some checks I've done, this particular case is different to the others
I've been using them. Seems also that GCPROTECT_XXX macros do exactly the
sam
t: Re: [DOTNET-ROTOR] GC Issues
Thank you very much for your help. I will try the
SetObjectReference(...)
function and see what happens now during execution. Hope GC issues will
be
gone now. I think that the "this" issue you mentioned should not happen
to
me, because the "this" obje
Thank you very much for your help. I will try the SetObjectReference(...)
function and see what happens now during execution. Hope GC issues will be
gone now. I think that the "this" issue you mentioned should not happen to
me, because the "this" object is already stored in a HANDLETABLE, and I
thi
All stores of object references into GC heap have to go via write
barrier so that GC is notified about them.
newObject->param1 = param1;
newObject->param2 = param2;
should be something like:
SetObjectReference(&newObject->param1, param1);
SetObjectReference(&newObject->param2, param2);
Al
