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
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,
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
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
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;
We found a fix for our problem. We created a new work space. Once
created, we copied our project folders but not the project files (eg.
.project).
It seems over time these project files must have been corrupted or possibly
uploaded to svn and downloaded by a different person.
On Thu, Jan 31,
