The number key button selection & default cancel action didn't work. This fixes them.
Also, the listeners created by MultiSelectWindow were never destroyed, and they would just live eternally in the SynchronousList for listeners in each Controller. They wouldn't get invoked if the window were removed since there is a check for that, but new ones would be added to the list every time the window is shown.
MultiSelectWindow is not the only class with this type of leak - e.g. Window itself has it too. Since there is no mechanism for automatically removing listeners whose associated context is destroyed, the listeners must be destroyed manually by any object that creates them.
I'll go through the Listen calls and submit pull requests accordingly, since there are not that many of them, but maybe in the future an automatic listener cleanup system should be added.
The number key button selection & default cancel action didn't work. This fixes them.
Also, the listeners created by MultiSelectWindow were never destroyed, and they would just live eternally in the SynchronousList for listeners in each Controller. They wouldn't get invoked if the window were removed since there is a check for that, but new ones would be added to the list every time the window is shown.
MultiSelectWindow is not the only class with this type of leak - e.g. Window itself has it too. Since there is no mechanism for automatically removing listeners whose associated context is destroyed, the listeners must be destroyed manually by any object that creates them.
I'll go through the Listen calls and submit pull requests accordingly, since there are not that many of them, but maybe in the future an automatic listener cleanup system should be added.