Hello Paul, I noticed a similar problem years ago in the flex 4.1 SDK, but it could have been there for a while before that. We used a pretty simple workaround that you could try: https://mickpowellstips.blogspot.com/2010/11/dropdownlist-memory-leak-flex-41.html. It might fix your issue, and I doubt it will do any harm to give it a whirl… There might be a better approach as well, but that was the way we solved it.
All the best, Mick > On Feb 2, 2019, at 12:55 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > Hard to say for sure, but one thing to watch out for with ComboBox is running > any code that accesses the dropdown property. ComboBox by itself should > know how to destroy and unhook the dropdown, but if you run code that access > dropDown after ComboBox thinks it cleaned up, then it will get stuck in > memory again. > > HTH, > -Alex > > On 2/1/19, 10:19 PM, "Paul Stearns" <pa...@compuace.com.INVALID> wrote: > > Alex: > > I have found that using a custom combo box I built causes the module that > contains it to stay in memory. > > If I create a new instance but do not access it, everything is fine, As > soon as I touch the dataprovider, it will not allow the parent module to > unload (even if I set the dataProvider to null). I changed it to a standard > combobox, and everything is ducky, but that doesn't have the features I need. > > If you could take a look at my ValidatedComboBox function and see if it is > something obvious, I'd appreciate it. > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&data=02%7C01%7Caharui%40adobe.com%7C231ee986cc774540946a08d688d65832%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636846851513368107&sdata=tT4%2BqA90aBbCdypmr59FIGnRgyJFN72d42fKr75dRE0%3D&reserved=0 > > Paul R. Stearns > Advanced Consulting Enterprises, Inc. > > 15280 NW 79th Ct. > Suite 250 > Miami Lakes, Fl 33016 > > Voice: (305)623-0360 x107 > Fax: (305)623-4588 > > > >
