From Gnash Project Wiki

Jump to: navigation, search

Soft references are 'movieclip' value types in ActionScript. They are special in that they don't keep the pointed object alive, they become invalid when the pointed object is removed and they point to any new object which is placed at the same target. Referencing string seems to be the movieclip target. Anyway some tests show oddities introduced when changing the _name property of any component of the full target.


External information

Here are some more external informations:


Attempts to test this are in the testcase.

Suppose you don't want to review all those things, here is a short test, see if you could provide a model to solve/survive the following tests:)

 //create a movieclip
 mcRef = this.createEmptyMovieClip("mc", 10);
 check(mc ==;    
 check(mcRef ==; 
 //change the "_name" property
 mc._name = 'changed';
 check(mc == undefined);           
 check(mcRef == _level0.changed);  
 // remove the created moiveclip
 check(typeof(mc) == 'undefined');    
 check(typeof(mcRef) == 'movieclip'); 
 check(mc == undefined);  
 check(mcRef.valueOf() == null); 
 //re-create a movieclip again
 this.createEmptyMovieClip("mc", 20);
 check(mc ==;    
 check(mcRef ==;

Current implementation


MovieClip values are stored as string copies of the clip's target path. When a movieclip value is dereferenced it resolves the target path dynamically and returns any object found, possibly NULL if none is found.

A problem shown by the recent tests in testcase is that changing the _name property of any component of the path makes dynamic resolution of the cached target path fail, while the proprietary player seems to retain the reference to it's original (!!).

Any help with solving this puzzle is welcome.


MovieClip values are stored by pointer. When a movieclip value is dereferenced, the status of the pointed-to MovieClip is checked. If it is unloaded, then it's targetPath is used to find any other MovieClip placed at that target, and the new one is returned (or NULL, of no other).

Question: How do you know the instances pointed by the pointer is valid(not destroyed) before you dereference it? --zou

Answer: as_value checks with isUnloaded(). This is sub-optimal but works correctly, as any removed-but-still-referenceable sprite can still be found by target value, so any dereferencing will keep scanning the displaylist for a match in target name, which could be avoided by checking for another flag (ie: isRemoved) in which case we'll need to notify real removals of the characters *after* executing any pending onUnload event hanlder (should'nt be too hard, doing so in DisplayList::removeUnloaded)

Should be checked what happens with 'this' variables in onUnload methods. already tested, see misc-ming.all/unload_movieclip_test1.c