That is a weird one. Nothing obvious I can see. It might be time to create a simple test case.
In could also be an interaction where the setting of the height isn't the problem, it is the setting of the height along with something else. To test that, remove everything except the height=20 and see if it is still a problem. -Alex On 9/10/14 3:00 PM, "DarrenEvans" <[email protected]> wrote: >So further to this....I'm baffled! > >I've tracked down the line that is causing the leak. However, I'm at a >loss >as to why. In the constructor of jabbypanda's DataField4 it does the >following (bearing mind it extends mx.controls.DateField): > > public function DateField4() { > super(); > > // Allow manual text date input. > editable = true; > > height = 20; > > labelFunction = displayDate; > parseFunction = DateUtil.parseStringToDate; > > this.addEventListener(CalendarLayoutChangeEvent.CHANGE, >onChangeDate); > this.addEventListener(FlexEvent.ENTER, onEnterKeyPressed); > this.addEventListener(FocusEvent.FOCUS_IN, onFocusIn); > } > >Now, if I comment out the line that sets the height = 20 the leak >disappears. WTF?! > >Github link to the source code: https://github.com/JabbyPanda/DateField4 > > >DarrenEvans wrote >> 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-tp7770p7973.html >Sent from the Apache Flex Users mailing list archive at Nabble.com.
