About SwitchToDialog

Question

Hi, EW Team:

    When I use SwitchToDialog(), I find that the dialog switched out is still active, a timer in it can still trigger event. To recycle the memory used by it immediately, do I have to use Remove() on it? When will the dialog that has not been removed by Remove() be recycled automatically?

    Thank you.

Best regards.

Stephen

Answer 1

Hello Stephen,

two assumption:

Possibility 1: the object representing the old dialog is still referred by other existing objects. This prevents the dialog from being disposed. The object continues existing.

Possibility 2: You invoked SwitchToDialog() in context of the old dialog. This causes the new dialog to appear embedded inside the old dialog. Both dialogs continue existing simultaneously.

From experience in preceding support cases I would go for the second possibility. Please check the code containing the invocation of SwitchToDialog(). To work correctly, the method should be invoked in context of the same GUI component, which acts as the original owner of the dialog to dismiss and as new owner for the dialog to present. One possible implementation could be:

OldDialog.Owner.SwitchToDialog( NewDialog, ... );

I hope it helps you further. For more details see also: SwitchToDialog().

Best regards

Paul Banach

Comments

Hi, Paul:

       I define a slot which calls SwitchToDialog() in the owner class. The slot is signaled as a slot variable by the old dialog when user interacts. So I think in my design, the old and new dialogs share a common owner. 

  Calling the method SwitchToDialog() causes the new dialog component to replace the entry on top of an internal stack containing all dialogs existing at the moment in context of 'this' owner component. The dialog component on top of the stack is considered as the active dialog - the dialog, the user may interact with. Other dialogs lying in the background are automatically deactivated and they are suppressed from being able to receive and process user inputs.

     According to the document of SwitchDialog above, the old dialog is in background, and not released, so timer in it can be still active, right?

    Thank you.

 

Best regards.

Stephen

     

---

Hi Stephen,

According to the document of SwitchDialog above, the old dialog is in background, and not released, so timer in it can be still active, right?

The cited documentation explains the general idea of the internal dialog stack. SwitchToDialog() in fact replaces the dialog on top of the stack. In turn, PresentDialog() presents a new dialog overlaying so all dialogs presented before. In last case, multiple dialogs will exist (stacked one above the other). In the first case, the new dialog replaces the old one. Assuming there is no other reference to the object representing the old dialog, the object should be deleted during the next garbage collection.

A further idea: are the dialogs instantiated dynamically (using the new operator) or are they objects embedded inside other GUI components? In the last case, the embedded object are part of the superior component and are not deleted unless the superior component is deleted. Can you check it?

Well, I'm not sure whether it helps you further. If you cannot isolate the cause of the problem, you can reduce your project to the simplest example possible and upload it to this forum thread for analysis.

Best regards

Paul

---

Hello Stephen,

thank you for providing us the example project via e-mail. For the sake of completeness I have uploaded this project also to this thread. It can be found here: example project. To upload files to a thread you can use the following button:

The still running timers can be explained by a peculiarity of Garbage Collection when prototyping an application. In target system, the Garbage Collection runs after each screen update. That means all unused object sare released almost immediately. During prototyping, we trigger the Garbage Collection seldom, approx. every 0.25 .. 10 sec. depending on the activity in the application. An object not used anymore can therefore continue living for few seconds. A timer existing in such object can thus continue fireing. Please see also the section Force Garbage Collection.

In your concrete example, the timers are configure to run periodically (the property Period is configured). One possible approach to correct the behavior could thus be the configuration of the timers as 'single shot' timers and not 'periodic' timer. For this purpose you set the property Period to the value 0 and set the property Begin to the value 5000. Doing this you specify only the initial delay and no period. The timers will fire only once. See also Specify the timer interval and the initial delay.

Furthermore, in case of any random events like user or system events but also periodical timer events, it is recommendable to test whether the component in question is still acting as dialog. Due to race conditions and delays during transitions between dialogs, it is not excluded that a component receives an event although it does not act anymore as dialog (it has been dismissed). Please see the section Identify the active Dialogs and avoid race conditions explaining such possible error situation. This chapter explains also how to handle such race conditions.

In your case one possible approach could be following if-condition at the beginning of the slot methods triggered by the timers. The condition tests whether the timer does belong to the actually active dialog. If not, the event is ignored. For example, the slot method slotSwitch2Panel1 is expected to be called from Panel3. Therefore test whether Panel 3 is still the active dialog:

I hope it helps you further.

Best regards

Paul

---

Hi, Paul:

     Thank you for your detailed explanation.

Best regards.

Stephen.