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.
>>

Reply via email to