This project is read-only.

ModernDialog ShowDialog return result issue between 1.0.4 and 1.0.5

Jul 11, 2013 at 4:17 PM
There was an diff between 1.0.4 and 1.0.5 with the following code.
var v = new ModernDialog
                Title = "Common dialog",
                Content = new LoremIpsum()
            v.Buttons = new Button[] { v.OkButton, v.CancelButton };
            var r = v.ShowDialog();
            ModernDialog.ShowMessage(string.Format("HasValue:{0}\tValue:{1}", r.HasValue, r.Value),
                "RESULT", MessageBoxButton.OK);
When click "OK" button, the result on version 1.0.4 is "HasValue:true Value:true",
but on version 1.0.5 the result value is false.
And I found that the DialogResult in ModernDialog.cs has been changed.
Jul 11, 2013 at 10:13 PM
Jul 12, 2013 at 1:58 AM
Yes, ShowMessage()'s result is correct, and sometimes we need to get the ShowDialog()'s result.
But changeset#101528 only return "MessageBoxResult dialogResult " in ShowMessage() method.
Jul 14, 2013 at 12:41 PM
Sorry, now I get what you want. ShowMessage() is a static method of ModernDialog, so the result can be changed as the author will. But ShowDialog() is a Method of the underlying System.Windows.Window. Its result value is provided be .NET, no chance to change.

The return value of WPF's System.Windows.Window.ShowDialog() is different from that of System.Windows.Forms.Form.ShowDialog(). In the good old times it was a DialogResult enumeration. Nowadays it is a nullable boolean. mu:i's ModernDialog.ShowMessage() was behaving like System.Windows.Window.ShowDialog() now it works like System.Windows.MessageBox.Show(), but System.Windows.Window.ShowDialog() can only be the same as defined in .NET.
Sep 27, 2013 at 6:28 PM
Now I run into the same problem. ModernUI doesn't provide a value to the DialogResult property of the underlying Window. So ShowDialog() can't give a useful result.

The current constructor of ModernDialog should be changed to
                        this.closeCommand = new RelayCommand(o => {
                                var result = o as MessageBoxResult?;
                                if (result.HasValue) {
                                        this.dialogResult = result.Value;
                                        // add the following line
                                        this.DialogResult = result.Value == MessageBoxResult.OK || result.Value == MessageBoxResult.Yes;
Oct 30, 2013 at 11:00 AM
Yea, now seeing this problem. I need to show my own View + ViewModel in a ModernDialog, so I create the ModernDialog and set the BackgroundContent property. But when I show the dialog, the return value of ShowDialog is always false. Are you planning to fix this? I can probably work around it by listening to the individual click events, but would prefer a functioning ShowDialog method.
Nov 29, 2013 at 9:38 PM
Hey so my solution was to add this to the ModernDialog.cs file:

pragma warning disable 1591

    public MessageBoxResult Result
        get { return dialogResult; }
        set { dialogResult = value; }

pragma warning restore 1591

The #pragma's are there because otherwise you get a build error, something like: "Missing XML comment for publicly visible type or member."

Then in the code after <ModernDialog object>.showDialog() finishes, you can call <ModernDialog object>.Result to get the dialogResult.

Hope this helps somebody!
Jan 6, 2014 at 6:22 PM
does anyone have an idea why this fix hasn't been incorporated to the main branch? This seems like this fixes core functionality and I would much rather have this in an official nuget package rather than building my own mui lib and using that.
Jan 30, 2014 at 11:48 PM
I'm also having issues regarding this. The ModernDialog method "ShowDialog()" returns false regardless of clicking the OK button.
Feb 3, 2014 at 11:03 AM
I've use ".OkButton.Click +=" to avoid this problem.
Apr 11, 2014 at 12:32 PM
Exactly. It is a bug in the core functionality. It makes the dialog unusable outside of very basic scenarios. I also don't want to build my own version of ModernUI.

@kozw: Is it possible to merge the fix to the main branch and publish an official NuGet package that would contain the fix?