Related to #15041 and #15105

Summary of the issue:
Ever since Add-on Store was introduced NVDA was intermittently failing to restart on my machine. This occurred only when I've opened Add-on Store before restarting. After debugging it turned out the following happens:

When exiting NVDA had to destroy the store dialog, as it was kept alive due to circular reference
The new instance of NVDA tried to wait for the old instance to exit, but since the exit process took extra long due to destroying the dialog the new copy gave up and didn't start
Description of user facing changes
NVDA should no longer fail to restart intermittently after opening and closing Add-on Store.

Description of development approach
The reference to one of BoxSizerHelper objects was stored on the store dialog. Since each BoxSizerHelper also stores reference to its parent the store dialog could not be destroyed properly when closing. This circular reference cycle was broken by no longer storing the BoxSizerHelper on the instance - it is either used as a local variable, or passed to the method which needs it as an parameter.

Testing strategy:
Ensured store dialog is still functioning
Stress tested restarting NVDA on a machine where this was failing and verified it restarts successfully every single time
Ensured no instances are stored in gui.settingsDialogs.SettingsDialog._instances when the Add-on Store dialog is closed
Known issues with pull request:
Storing a BoxSizerHelper as a dialog member is an easy mistake to make in the future. I will submit a PR which makes it less likely to occur by storing a weak reference to the parent in the helper instance. Since this is a bigger and more risky change it will target master
The approach taken by Add-on Store: prevent duplicate instances from opening #15105 i.e. ignoring the warning about existing instances is sub-optimal. As demonstrated by this PR ignoring these alive references may cause issues in unrelated areas of NVDA. In my opinion we should restore the old behavior i.e. live references should once again cause a warning. If this is fine I'll submit a PR to that effect against master.

…hey are closed (#16054)

Follow up from PR #16019

Summary of the issue:
Normally it should not be possible to open the same NVDA's settings dialog multiple times. To make sure this does not happen settings dialog constructor verifies if the given dialog is already opened, and either focuses it when it is, or creates a new dialog when it is not. In rare cases the dialog should be destroyed after user closed it, but due to circular reference Python's garbage collector cannot clean it up. Before PR #15105 this was causing an error making it impossible to reopen the dialog. In that PR the behavior was changed, so that when the instance is still kept alive it is just marked as created and reused. As described in PR #16019 when dialogs are not destroyed properly NVDA may malfunction, so having an error and non working dialog is better than a hard to debug error in other part of NVDA.

Description of user facing changes
This should not have user visible impact, as long as there are no dialogs which fail to be destroyed when they are closed.

Description of development approach
When there is an existing instance of a given dialog which is marked as destroyed there is an error in the log, and no other instances of this dialog can be created.

…hey are closed (nvaccess#16054)

Follow up from PR nvaccess#16019

Summary of the issue:
Normally it should not be possible to open the same NVDA's settings dialog multiple times. To make sure this does not happen settings dialog constructor verifies if the given dialog is already opened, and either focuses it when it is, or creates a new dialog when it is not. In rare cases the dialog should be destroyed after user closed it, but due to circular reference Python's garbage collector cannot clean it up. Before PR nvaccess#15105 this was causing an error making it impossible to reopen the dialog. In that PR the behavior was changed, so that when the instance is still kept alive it is just marked as created and reused. As described in PR nvaccess#16019 when dialogs are not destroyed properly NVDA may malfunction, so having an error and non working dialog is better than a hard to debug error in other part of NVDA.

Description of user facing changes
This should not have user visible impact, as long as there are no dialogs which fail to be destroyed when they are closed.

Description of development approach
When there is an existing instance of a given dialog which is marked as destroyed there is an error in the log, and no other instances of this dialog can be created.

…hey are closed (nvaccess#16054)

Follow up from PR nvaccess#16019

Summary of the issue:
Normally it should not be possible to open the same NVDA's settings dialog multiple times. To make sure this does not happen settings dialog constructor verifies if the given dialog is already opened, and either focuses it when it is, or creates a new dialog when it is not. In rare cases the dialog should be destroyed after user closed it, but due to circular reference Python's garbage collector cannot clean it up. Before PR nvaccess#15105 this was causing an error making it impossible to reopen the dialog. In that PR the behavior was changed, so that when the instance is still kept alive it is just marked as created and reused. As described in PR nvaccess#16019 when dialogs are not destroyed properly NVDA may malfunction, so having an error and non working dialog is better than a hard to debug error in other part of NVDA.

Description of user facing changes
This should not have user visible impact, as long as there are no dialogs which fail to be destroyed when they are closed.

Description of development approach
When there is an existing instance of a given dialog which is marked as destroyed there is an error in the log, and no other instances of this dialog can be created.

Related to nvaccess#15041 and nvaccess#15105

Summary of the issue:
Ever since Add-on Store was introduced NVDA was intermittently failing to restart on my machine. This occurred only when I've opened Add-on Store before restarting. After debugging it turned out the following happens:

When exiting NVDA had to destroy the store dialog, as it was kept alive due to circular reference
The new instance of NVDA tried to wait for the old instance to exit, but since the exit process took extra long due to destroying the dialog the new copy gave up and didn't start
Description of user facing changes
NVDA should no longer fail to restart intermittently after opening and closing Add-on Store.

Description of development approach
The reference to one of BoxSizerHelper objects was stored on the store dialog. Since each BoxSizerHelper also stores reference to its parent the store dialog could not be destroyed properly when closing. This circular reference cycle was broken by no longer storing the BoxSizerHelper on the instance - it is either used as a local variable, or passed to the method which needs it as an parameter.

Testing strategy:
Ensured store dialog is still functioning
Stress tested restarting NVDA on a machine where this was failing and verified it restarts successfully every single time
Ensured no instances are stored in gui.settingsDialogs.SettingsDialog._instances when the Add-on Store dialog is closed
Known issues with pull request:
Storing a BoxSizerHelper as a dialog member is an easy mistake to make in the future. I will submit a PR which makes it less likely to occur by storing a weak reference to the parent in the helper instance. Since this is a bigger and more risky change it will target master
The approach taken by Add-on Store: prevent duplicate instances from opening nvaccess#15105 i.e. ignoring the warning about existing instances is sub-optimal. As demonstrated by this PR ignoring these alive references may cause issues in unrelated areas of NVDA. In my opinion we should restore the old behavior i.e. live references should once again cause a warning. If this is fine I'll submit a PR to that effect against master.

…hey are closed (nvaccess#16054)

Follow up from PR nvaccess#16019

Summary of the issue:
Normally it should not be possible to open the same NVDA's settings dialog multiple times. To make sure this does not happen settings dialog constructor verifies if the given dialog is already opened, and either focuses it when it is, or creates a new dialog when it is not. In rare cases the dialog should be destroyed after user closed it, but due to circular reference Python's garbage collector cannot clean it up. Before PR nvaccess#15105 this was causing an error making it impossible to reopen the dialog. In that PR the behavior was changed, so that when the instance is still kept alive it is just marked as created and reused. As described in PR nvaccess#16019 when dialogs are not destroyed properly NVDA may malfunction, so having an error and non working dialog is better than a hard to debug error in other part of NVDA.

Description of user facing changes
This should not have user visible impact, as long as there are no dialogs which fail to be destroyed when they are closed.

Description of development approach
When there is an existing instance of a given dialog which is marked as destroyed there is an error in the log, and no other instances of this dialog can be created.