We are using this "dialog-on-dialog" approach in order to stack a multitude of screens on top of each other as the user walks through the application logic.
So yes, we present one dialog inside another indeed.
By using DismissDialog(), we rely on the application to remember which dialog to return to. If we now had to individually remember which widget to re-enable, code would lose its maintainability.
hmmm ... I don't know your implementation, but it should not be necessary to present one dialog inside another just to achieve the effect of stacking dialogs. In most cases it is sufficient for the application to present all dialogs within a common owner component (usually the Application component).
The order of how the dialogs are stacked corresponds then to the order in which the user walks through the application logic. Invoking DismissDialog() will automatically return to the preceding dialog - what you expect, so far I have understood your application case. Is there possibly some misunderstanding?
So far, we have addressed this behaviour by individually disabling widgets and touch handlers ...
This would be a working approach - but also labor and error intensive. Another possibility would be to make the actually active dialog modal. This prevents all other GUI components and touch handlers from being able to react to user inputs. For this purpose:
1. Just in the moment when you present a new dialog you make it modal:
// Evtl. Avoid race conditions
if ( !IsCurrentDialog())
// Create an instance of the new dialog
var Core::Group dialog = new Application::Dialog;
// Present it and ...
PresentDialog( dialog, null, null, null, null, null, null, null, null, false );
// ... make it modal
GetRoot().BeginModal( dialog );
2. Just in the moment when you dismiss the actual dialog, also end its modal state. For example, when the dialog dismisses itself:
// Evtl. avoid race conditions
if ( !IsCurrentDialog())
// End the modal state of the dialog and ...
GetRoot().EndModal( this );
// ... dismiss it
Owner.DismissDialog( this, null, null, null, null, null, false );
Do you have any recommendation about how a dialog could intercept the moment in which it becomes visible again, so it could properly re-enable its widgets by itself?
So far I have understood your application case, I don't think this would be possible. Since the dialogs are nested one inside another, all dialogs are visible and all dialogs are active at the same time. There is no state alternation which can be monitored. Usually, a state alternation of a GUI component is reported to it via its method UpdateViewState(). There you can also implement code to react to the alternation. See also: Common component states.
Does it help you further?