As you can see, this has been a problem since 2014. I'm wondering if there is a good reason for why ContentDialog button commands ignore CanExecute changed result, and fails to disable buttons.
The following are the only times that CanExecute is called:
1. After content dialog is rendered AND only after primary button is pressed.
The issue with this is that by the time you press the button, the dialog closes and it doesn't matter if the button is disabled/enabled now.
The other issue is that the command assigned to PrimaryButtonCommand will never call CanExecute even after calling RaiseCanExecuteChanged() directly.
This seems like a bug, but seeing it hasn't been changed since '14, I'm wondering if this design is intentional. In addition to any suggested workarounds (none of the above links seem to solve the issue or are too specific to an implementation), I'm hoping this will get noticed by a development team.
Working on UWP, Windows 10 v.1903