Great suggestion. Might do that to track down the problem as I have proved something else.
After investigation we are using the 0.5.swc of com.jabbypanda.controls.DateField. This has not been touched or even looked at within our system for YEARS. Looking online there is a 0.51 of this component and maybe even a newer Flex 4 version (I think the one I can see supercedes the one we are using). I have now proven the leak is specifically related to the jabbypanda code! If I change our component to subclass directly the basic mx:DateField rather than the jabbypanda one, all the memory leaks in this area disappear. So.....think I'm getting there... Alex Harui wrote > One test would be to make a simple app with just the DateField in it and > see if it goes away. That should be small enough to be able to use Flash > Builder to track down any leaks. > > PopUps can easily cause memory leaks. They often set up > global/systemManager event listeners. PopUps are not parented by the > top-level so removing the top-level doesn't cause the popUp to get removed > from the display list and usually it has a reference to a shared > DataProvider or the part of the control that is parented by the top-level. > > On the other hand, we try to write our controls like DateField to not > create and parent the popup until the user actually requests it, so there > are often tests where you don't open the DateField and the top-level does > go away, then you open the DateField and the top-level doesn't go away. > > -Alex -- View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Using-Adobe-Scout-to-locate-memory-leak-tp7770p7971.html Sent from the Apache Flex Users mailing list archive at Nabble.com.
