Paul:
OK, good to know you got past one issue.
FWIW, storing callbacks from the module is what I call "reaching down". The
main app has effectively reached down into the module and grabbed hold of
something. The pattern closest to callbacks is event dispatching and event
dispatching has the advantage of supporting weak-reference listeners. You
could try storing callbacks in weak-reference dictionaries as well if you are
trying to find a minimal refactor.
HTH,
-Alex
On 2/2/19, 5:25 PM, "Paul Stearns" <pa...@compuace.com.INVALID> wrote:
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 <aha...@adobe.com.INVALID>
Sent: 2/2/19 7:46 PM
To: "pa...@compuace.com" <pa...@compuace.com>, "users@flex.apache.org"
<users@flex.apache.org>
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: "pa...@compuace.com"
Date: Saturday, February 2, 2019 at 3:22 PM
To: Alex Harui , "users@flex.apache.org"
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: "users@flex.apache.org" , "pa...@compuace.com"
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: "users@flex.apache.org" , "pa...@compuace.com"
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%7C33aad47706c54824ba5508d6897674bd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847539191479854&sdata=QYVOWpwEK%2FHy9XqMiTqVtojoFF0YpyCRRcoe5Z5Vq70%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
