Hello Robert,
you have correctly deduced the cause of the behavior. Once the Timer is enabled it continues running until the object is disposed by the Garbage Collection. In the target system the Garbage Collection is triggered usually after each screen update. In turn, during the prototyping, the Garbage Collection runs seldom. It can even take up to 10 seconds before new Garbage Collection cycle is started. See for example: Force garbage collection.
A simple workaround is to disable the Core::Timer before dismissing, but would using UpdateViewState to check whether the dialog is displayed be a better alternative?
You could disable the Timer when the affected component loses the Dialog state. For this purpose implement in the component the UpdateViewState() method and test there for the Dialog state alternation. When the state is not set anymore, disable the Timer. For example:
if ( Timer.Enabled && !aState.contains( Core::ViewState[ Dialog ]))
Timer.Enabled = false;
More simple and consequent would be to add following if-condition to the slot method triggered by the Timer. The condition verifies whether the actual component still does act as a dialog. If not, the Timer event is ignored. Such test conditions are generally recommended in all methods triggered by user, timer or any other random events to avoid race conditions (see also Identify the active Dialogs and avoid race conditions):
if ( !IsDialog( false ))
return;
Also, please note that you can configure the Timer to expire only once. Possibly, you don't want the periodical expirations?
I hope it helps you further.
Best regards
Paul Banach
