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.