47 views
in GUI Development by
Hi,

I have a component that has a Core::Timer which triggers a slot that uses the device interface to sound a beeper. When the parent calls DismissDialog to remove the dialog the Core::Timer continues to trigger the slot even though the dialog is no longer displayed. Is this expected behaviour? I can see how it could be as the object continues to exist until it is garbage collected but I'm a bit surprised that I haven't seen this before.

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?

thanks, ...rob

1 Answer

0 votes
by
 
Best answer

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

by
Thanks very much - this is very helpful. Hadn't spotted the option of setting a negative Period in Core::Timer (in spite of it being in the help!) so that's useful too.

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...