For those not watching the bug, the test case in the bug [1] unloaded properly after I commented some stuff out to get it to compile.
[1] https://issues.apache.org/jira/browse/FLEX-34194 On 4/9/14 5:31 PM, "jude" <flexcapaci...@gmail.com> wrote: >It sounds like there is still a reference somewhere. I stepped through the >dataProvider property in the past because there is an confusing / deferred >way that the list base classes keep track of selected indexes / selected >items when you update or assign the dataProvider but I haven't looked at >it >recently enough to remember off hand. I'll have to check into it again but >that's where I'd start in the mean time. > >Also, just to make sure, try with a release build and release player and >see if it makes any difference, > >4) Debug-versions of a module on the Debugger Player can also lead to a >module being stuck in memory. Debug-versions contain debug information >that >can get registered with the debugger and not released. The final test is >always to use release versions of the modules and application on a release >version of the player. > > >On Wed, Apr 9, 2014 at 5:11 AM, Davorian <don.fasa...@gmail.com> wrote: > >> Hi Jude, >> >> Yep I've tried that, unfortunately it didn't work. :-| >> >> I'm aware there must a reference to the module created by doing this, >> however, I'm of the belief that it's within the framework, as setting >>the >> dataProvider to null does not work, how am I to remove references from >>such >> a simple case? ( And what reference is it?) >> >> Regards. >> >> >> >> -- >> View this message in context: >> >>http://apache-flex-development.2333347.n4.nabble.com/In-Apache-Flex-4-10- >>and-4-12-why-does-setting-a-dataProvider-on-a-spark-datagrid-prevent-the- >>module--tp36715p36718.html >> Sent from the Apache Flex Development mailing list archive at >>Nabble.com. >>