Alex: I should have been more clear. The validatedCombobox no longer appears to keep my test module in memory. By replacing access to the dropdown, and relying on invalidateDisplayOptions to synchronize everything seems to work.
I also found something else that appears to be causing a problem, that I have started to correct. This is a fairly complex DB application with hundreds of tables, 30-40 of which are generally used to populate combo boxes and other list components. These tables are fairly static and up to 15-20 could be used in a single entry screen. In order to reduce network thrashing between the DB and the client computers, I wrote a public function that resides in the parent Application called loadComboList. When a request is made for this type of data in memory array collections are checked first, if they are null it then queries the DB, returns the data to the application to both be stored in globally accessible array collections, cloned and sent to the requesting module. If the data is in an array collection it is just cloned and sent back to the requesting module. The modules handle all this by passing a "call back function" to the parentApplication function, which is then stored in a "private var". This parentApplication private var never gets cleared so it is a reference to a public function in the module causing the module to not be GCed. Not the smartest code I ever wrote, (hindsight is 20/20) but it does make things run faster, until the memory leak wreaks havoc. I have started to rewrite this as a class which is instantiated in the module, but stores/reads its data in/from the parent application. I have tested it with a small live module (one query/combobox) and it seems to work. I am converting another 18 queries to test a much larger module, I will keep you posted, if you are interested. 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 ---------------------------------------- From: Alex Harui <[email protected]> Sent: 2/2/19 7:46 PM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: At least one memory leak problem is a custom combo box I use. Paul: I assume that means that your custom combobox is still causing a memory leak? IIRC, you have a test setup where you click a button to unload the module. Add another button that checks the number of children of systemManager.popupChildren.numChildren. That number should go up by one when the dropdown is accessed and go down by one after the module cleans up to try to unload. If it does go down by one, then the dropdown is probably going away and is not the problem. If it is there, then some code may still be accessing the dropdown property. Maybe override the dropdown property getter and trace who is accessing it. HTH, -Alex From: Paul Stearns Reply-To: "[email protected]" Date: Saturday, February 2, 2019 at 3:22 PM To: Alex Harui , "[email protected]" Subject: Re: At least one memory leak problem is a custom combo box I use. Alex: After I wrote my previous email, I changed the code to not access the dropdown. I was able to use "invalidateDisplayOptions," and use only the combobox items directly. I am still debugging. 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 ________________________________ From: Alex Harui Sent: 2/2/19 6:09 PM To: "[email protected]" , "[email protected]" Subject: Re: At least one memory leak problem is a custom combo box I use. It is fine to access the dropDown property as long as it doesn't happen after other clean up code runs. It might be worth debugging to see if the dropDown is the actual problem. It could be something else, like some eventhandler that handles an event you dispatch from your code keeps a reference to the combobox. So use the debugger or profiler or other means to see if the dropdown is still on the display list. You can report on the children in SystemManager.popUpChildren. You can verify that the ComboBox's destroyDropdown is being called. And then try to verify that dropDown is not accessed after that. HTH, -Alex On 2/2/19, 1:43 PM, "Paul Stearns" wrote: Alex: Yes this code does reference the DropDown component. The code is there to handle finding items and moving the cursor to the appropriate item. For example if the data is; dog cat bird and c-a-t is typed it finds cat and highlights it. If the data provider changes and the values become; dog lizard cat bird the component will still keep cat highlighted. Given the above as a requirement, how can I clear make the component eligible for GC? 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 ---------------------------------------- From: Alex Harui Sent: 2/2/19 1:55 AM To: "[email protected]" , "[email protected]" Subject: Re: At least one memory leak problem is a custom combo box I use. 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" 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%7Cfb19977d8bca48a31d7708d6895783f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847406335722938&sdata=ZQASYXvbPPMfWDk8kWtVTskwz1Z%2BPF7UVmXEWUBF%2Bek%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
