--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > More thoughts on locals containing handles. > > --- In [email protected], "brucexs" <bswitzer@> wrote: > > > > - > > Here is a related situation. What happens if a user does this: > > > > Function AKA > > local x = create an object with com > > global xAliased = x > > quit > > > > > Will local x be released, meaning xAliased is a dangling reference? > > As is, yes. Presumably not if I do this? > > Function AKA > local x = com.localcopy(com.create_object(...)) > global xAliased = x > quit > > and then what happens if I do this:
The above should be OK, I think, of course presuming that something outside of the script manually frees xAliased. That is what localcopy is for -- to prevent stuff created or passed into a script and assigned to a script local from being released. But the script writer must understand how it will be released somewhere else. I don't see rightnow how the above could be used to solve the for each situation; I think you need a clone function for that if you release for-each-created enumeration object at each iteration. for each obj in objCollection v[j] = obj.clone // if for each processing does auto release on obj endfor I am reluctant to go back to ref counting. It's probably only something you and I and Sheri and a couple of people in Korea care about, and it's liable to break com stuff that is pretty well working now while we go through some tedious debugging. > > Function AKA > local x = com.localcopy(com.create_object(...)) > . > . > . > com.unload > quit > > Your code needs to call a com function to release local x: but com no longer > in memory? What happens? The object signature will not be valid anymore, since it was unregistered by the com.unload. So the local will just be treated as a standard string (I guess you created object freed memory at com.unload). >
