92 views
in GUI Development by

Hi,

I am going through the Full Stack Dialog Architecture and I would like to know how I can force an "Effect" when I switch from one Dialog to another.

I have a Gauge Widget that I tied an Int32 Effect to it. I want to trigger the Int32 Effect when I switch back to the Dialog where the Gauge Widget Shows in the View.

As can be seen the "Settings" button on Activate call the "GoToSettings Slot" method which switches Dialog.

The Back button on Activate calls the "GoBack" Slot method to dismiss the present Dialog that goes back to the Dialog. But I'm trying to Re-trigger the Int32 Effect named "ScreenEffect" to exhibit its effect on the Gauge Widget. 

I tried to Set up a Boolean Property in the Base Dialogue and  set it as true to communicate a property variable change from one Dialogue View to another. By checking for the Base Property Boolean value in a method named "GuageReset". Then I tried to call the Int32 effect in this method like shown below but the "this.ScreenEffect.StartEffect;" code command did not do anything to the Gauge Widget.  Even when I tied it to a button and tried to call it.

// Slot Method GuageReset
if (this.BaseGuageVal == true)
{
  this.BaseGuageVal = false;
  Gauge.CurrentValue = 0;
  //this.ScreenEffect.ReverseEffect; 
  this.ScreenEffect.StartEffect;   
}

 

I made a separate button named "Guage" and tied "ScreenEffect.StartEffect" to the OnPress. This worked. I am wondering why the Slot method "GuageReset" as shown in the code did not work?

Thanks,

.

 

 

 

 

1 Answer

0 votes
by
 
Best answer

Hello,

I see two possible approaches how to implement this application case.

Option 1: In the dialog containing the Gauge (I suppose it is the class Application::HomeScreen) you implement a method which you invoke just in the moment when the user navigates back to this dialog. You tried similar approach (as far as I understood) and it did not work. Why this was the case is difficult to say. Assuming, you have added a method named Reactivate() to the dialog containing the Gauge, and the method contains code to restart the effect, following code could be used to trigger the method just after the DismissDialog() operation:

// First dismiss the 'settings' dialog
Owner.DismissDialog( this, Effects::SlideUpCentered, null, null, null, null, false );

// This makes the previous 'gauge' dialog the current dialog again. Try to access
// this dialog. Note the typecase to verify whether the preceding dialog was really the
// one containing 'gauge'.
var Application::HomeScreen dialog = (Application::HomeScreen)Owner.FindCurrentDialog();

// Trigger the Reactivate method for the gauge diualog
if ( dialog != null )
  dialog.Reactivate();

The disadvantage of this approach is, it requires the above code to be added wherever you return from a sub-dialog to the 'gauge' dialog. If this is only few times in your application, the approach is ok.

Option 2: Each time the user enters a new dialog or you return to a previously presented dialog, the method UpdateViewState() of the corresponding dialog is invoked automatically. This notifies the dialog about its state alternation. In your case you can implement code in the UpdateViewState() method and react when the dialog receives the state Focused. See also Managing component states. Summarised, 'Focused' means, the affected component is able to react to user inputs. The corresponding dialog is thus the active one.

The simplest would be to add following code to the method UpdateViewState() of the component containing the 'gauge':

This approach is simple. It has however, a side effect. The method UpdateViewState() is invoked in many different cases. This would cause the effect to be restarted unexpectedly. To avoid it, it is necesary to track the alternation of the Focused state. The simplest is you add a bool variable (e.g. named isFocused)  to the component containing the gauge and evaluate the variable within the UpdateViewState() implementation:

Now the effect is triggered when the dialog restores its 'Focused' state, means, when the dialog is active again.

Does it help you further?

Best regards

Paul Banach

by

Hi Paul,

Thanks for showing me the different methods, I think it should be useful if I'm following the "Full Stack" method per your Master Class Video # 7. But It seems to be working in the "Managed Screen" method in the same Master Class video #7. Looks like when I switch dialogs from Application::SettingScreen and going back to Application::HomeScreen by updating the container device property CurrentScreen with the enumerated selection in a slot method named "GoBack" residing in Application::SettingScreen dialog;  The code in "GoBack" slot method looks like this:

Application::Device.CurrentScreen = Application::ScreenType.Start;

The Int32.Effect is being automatically triggered and I see the Guage Widget following the outcome of the Int32 Effect named ScreenEffect.

Thanks,

MMD

 

 

by

Hello,

Device.CurrentScreen follows another approach. In this approach you switch the screens. Consequently, when you present the Settings Screen, the 'gauge' screen is dismissed and all related objects are released. Later when you 'return' to the 'gauge' screen, you in fact recreate this screen again. If the animation effect is enabled per default, it will be activated in such case automatically.

With this approach no nesting of screens (dialogs) is possible. In other words, it is limited to present 1 dialog at the same time. But may be it is sufficient for your application case? Nesting of dialogs expects the usage of PresentDialog() and DismissDialog() as you originally implemented.

By the way, to switch between two dialogs it is not necessary to implement the Device:CurrentScreen functionality as you found in a video. Except very special application cases you can achieve the same effect by directly invoking the method SwitchToDialog(). For example, instead of implementing following code:

Application::Device.CurrentScreen = Application::ScreenType.Settings;

you can do following:

GetRoot().SwitchToDialog( new Application::SettingsScreen, null, null,
                          null, null, null, null, null, null, null, false );

Doing this you have better control over the operation. So you can configure the animation associated to the dialog transition as well as initialize the dialog just before it is presented. For example:

var Application::SettingsScreen dialog = new Application::SettingsScreen;

dialog.SomeSetting1 = 1234;
dialog.SomeSetting2 = "Some Text ...";

GetRoot().SwitchToDialog( dialog, Effects::SlideLeftCentered, null, null, 
                          null, null, null, null, null, null, false );

Also the management of the additional enumeration can be avoided when using SwitchToDialog() instead of the Device object.

I hope it helps you further.

Best regards

Paul Banach

by

Hi Paul,

i wanted to try your Option 2 suggestion: "Each time the user enters a new dialog or you return to a previously presented dialog, the method UpdateViewState() " As shown below from your Option 2 suggestion.

image

 

But I could not find the "UpdateViewState" method for my derived screens.

Here are my screen setups:

Here is a derived screen "HmeScreen1"

In this Case I'm in derived screen named "HomeScreen1" which is inherited from "ScreenBase". Now How can I find this method "UpdateViewState" for this inherited "HomeScreen1" So that I can put in your suggested code for disabling and enabling the effect?

Thanks,

mmd

 

 

 

by

Hello,

the method UpdateViewState() is defined in the class Core::Group. Since all GUI components descend from this base class, they all inherit this method. The method is thus available in all GUI components, screens, widgets, etc. In order to edit the method in your own component, it is necessary to override it. Please see following section: Override an inherited method. This means in your concrete case following steps:

1. Look in Inspector window for the member named UpdateViewState() . The simplest is you enter the name of the member in the Search ... field.

2. Drag-and-drop the found member by pressing the keys CTRL+SHIFT into the Composer:

Now you can edit the method as usual. Please note, there are many members inherited from the base classes. The Composer window shows only those members which you have effectively overridden/modified. The non overridden members are hidden and can be found in Inspector window only. See also: Inherited members.

Most of our Component Templates contain already an overridden version of the UpdateViewState() method since it is used often. So if you add a new GUI component to your project by using the mentioned templates, these components contain the UpdateViewState() method per default. 

Does it help you further?

Best regards

Paul Banach

by

Hi Paul,

Thanks! That worked. 

Here is my Full Stack Setup using Timer triggered and UpdateViewState methods when I switch between Dialogs:

 

Here are how the Dialogs are activated and dismissed:

if (Owner != null)
{
 Owner.PresentDialog(new Application::SettingScreen,null,null,null,null,null,null,null,null,false);

}
if (Owner != null)
{
 Owner.DismissDialog(this, null,null,null,null,null,false);
}

Below are the Screens for each Dialog. I use a Device property to store the values of the Scroll bars and use the UpdatViewState method as you mentioned to Update the states of the Scroll bars when I switch between Dialogs. This way when I go back and forth between dialogs, I don't have to re adjust my scroll bar settings. I also used a Timer triggered Slot method to update the positions of the Scroll bars and Display values. Not sure, but made the updates of the widgets more robust.

 

 

 

 

 

 

Thanks,

mmd

 

 

 

Embedded Wizard Website | Privacy Policy | Imprint

...