{"action":"created","issue":{"url":"https://api.github.com/repos/MahApps/MahApps.Metro/issues/2260","labels_url":"https://api.github.com/repos/MahApps/MahApps.Metro/issues/2260/labels{/name}","comments_url":"https://api.github.com/repos/MahApps/MahApps.Metro/issues/2260/comments","events_url":"https://api.github.com/repos/MahApps/MahApps.Metro/issues/2260/events","html_url":"https://github.com/MahApps/MahApps.Metro/issues/2260","id":121428554,"number":2260,"title":"WPF MVVM mahapps can't close Custom Dialog","user":{"login":"Grunzfort","id":14816691,"avatar_url":"https://avatars.githubusercontent.com/u/14816691?v=3","gravatar_id":"","url":"https://api.github.com/users/Grunzfort","html_url":"https://github.com/Grunzfort","followers_url":"https://api.github.com/users/Grunzfort/followers","following_url":"https://api.github.com/users/Grunzfort/following{/other_user}","gists_url":"https://api.github.com/users/Grunzfort/gists{/gist_id}","starred_url":"https://api.github.com/users/Grunzfort/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Grunzfort/subscriptions","organizations_url":"https://api.github.com/users/Grunzfort/orgs","repos_url":"https://api.github.com/users/Grunzfort/repos","events_url":"https://api.github.com/users/Grunzfort/events{/privacy}","received_events_url":"https://api.github.com/users/Grunzfort/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-12-10T08:25:03Z","updated_at":"2015-12-10T20:01:50Z","closed_at":null,"body":"Well, I've been following the mahapps metro demo application and I saw the Custom Dialog via MVVM and yeah, its working fine.\r\n\r\n```C#\r\nprivate async void OpenUserAccountDialog()\r\n        {\r\n            CustomDialog = new CustomDialog() { Content = new CreateUserDialog() };\r\n            await DialogCoordinator.ShowMetroDialogAsync(this, CustomDialog);\r\n        }\r\n```\r\nThe above code works perfectly. Accessing the MainViewModel is no problem, I can do something like:\r\n```C#\r\npublic ActionCommand CloseDialogCommand\r\n        {\r\n            get\r\n            {\r\n                return new ActionCommand(p => CloseDialog());\r\n            }\r\n        }\r\n```\r\n\r\nThen call it from my XAML:\r\n```XAML\r\nCommand=\"{Binding DataContext.CloseDialogCommand, Mode=OneWay, RelativeSource={RelativeSource AncestorType={x:Type views:MainWindow}}}\"\r\n```\r\n\r\nNow the problem here is that for some unknown reason, the Command to close the dialog won't fire (which is the MainViewModel). Accessing the MainViewModel is working from UserControl to UserControl but now that it's been opened from the Dialog, I can't seem to fire the ActionCommand inside the MainViewModel that closes the Dialog using the same code from the above XAML. Are there other ways to call the fuction in the MainViewModel from the Other ViewModel? (I tried this but I failed, like trying to make this static or something)\r\n\r\nI've been stuck here and searching the internet for days. I hope someone could help me out here, please."},"comment":{"url":"https://api.github.com/repos/MahApps/MahApps.Metro/issues/comments/163734477","html_url":"https://github.com/MahApps/MahApps.Metro/issues/2260#issuecomment-163734477","issue_url":"https://api.github.com/repos/MahApps/MahApps.Metro/issues/2260","id":163734477,"user":{"login":"bloritsch","id":194574,"avatar_url":"https://avatars.githubusercontent.com/u/194574?v=3","gravatar_id":"","url":"https://api.github.com/users/bloritsch","html_url":"https://github.com/bloritsch","followers_url":"https://api.github.com/users/bloritsch/followers","following_url":"https://api.github.com/users/bloritsch/following{/other_user}","gists_url":"https://api.github.com/users/bloritsch/gists{/gist_id}","starred_url":"https://api.github.com/users/bloritsch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bloritsch/subscriptions","organizations_url":"https://api.github.com/users/bloritsch/orgs","repos_url":"https://api.github.com/users/bloritsch/repos","events_url":"https://api.github.com/users/bloritsch/events{/privacy}","received_events_url":"https://api.github.com/users/bloritsch/received_events","type":"User","site_admin":false},"created_at":"2015-12-10T20:01:50Z","updated_at":"2015-12-10T20:01:50Z","body":"If the dialog box is displayed in the AdornerLayer, then you might be running into the same issue that you can get with context menus in DataGrids.  Basically, your visual tree in an adorner layer stops at the adorner layer and never gets to the ancestor type {x:Type views:MainWindow}.\r\n\r\nTo work around this issue, you'll have to have a proxy element defined in a higher context as described here: http://stackoverflow.com/questions/29361921/get-row-in-context-menu-command-parameter-mvvm\r\n\r\nThe issue is the fact that context menus, popups, adorners, etc. live in a completely different visual tree than the main window.  You'll need to have a named reference that you can use and change your binding to:\r\n\r\n   {Binding DataContext.CloseDialogCommand, Mode=OneWay, ElementName=Proxy}\r\n\r\nAs an aside, you might want to do a Debug.WriteLine(\"CanExecuteCalled\") in the ActionCommand to show just how often it will be queried when you tie in to the CommandManager.RequeryRequested callback.  It's quite enlightening, and it was a source of performance problems for a very complex application we are developing.  Having an explicit RaiseCanExecuteChanged() that can be called every time there is actually a change worthy of rechecking seemed to make things better for us.  Although you actually have to have the same CommandObject in your getter for that to work.\r\n\r\nIn our code the equivalent would work like this:\r\n\r\n    public MainViewModel()\r\n    {\r\n        CloseDialogCommand = new ActionCommand(p => CloseDialog());\r\n    }\r\n\r\n    public ActionCommand CloseDialogCommand  { get; private set; }\r\n\r\n    public void HandleSomeStateChangingEvent()\r\n    {\r\n        CloseDialogCommand.RaiseCanExecuteChanged();\r\n    }\r\n\r\nThere are far fewer events that actually change the state of when a command can execute than queries just because the mouse hovered over a focusable control."}}