gistfile1.txt

        public async void SaveDocument()
        {
            if (IsWorking) return;
            var doc = MDI.ActiveItem as DocumentViewModel;
            if (doc != null)
            {
                using (DoingWork(string.Format("Saving {0}", doc.MarkpadDocument.Title)))
                {
                    await doc.Save();
                    await TaskEx.Delay(5000);
                }
            }
        }

        //If I add this guy, I get a 5 second UI thread lockup... wtf
        public bool CanSaveDocument
        {
            get { return !IsWorking; }
        }

I cant see any reason why CM blocks. This is what should happen:

• Call SaveDocument
• DoWork sets IsWorking, Fody raises Property Changed for IsWorking and CanSaveDocument
• await doc.Save(); yields so UI thread is now free
• WPF/CM handle PropertyChanged events
• Because CanSaveDocument raised a changed event, CM and WPF commanding should call CanSaveDocument, which returns false. Button should get disabled
• doc.Save returns, execution of the SaveDocument state machine continues, hits await TaskEx.Delay(5000), which yields execution again, so UI thread is free
• State machine continues after 5 seconds, DoingWork is disposed, which sets IsWorking to false, which raises property changed for IsWorking and CanSaveDocument
• WPF/CM should re-enable the button

If I use an ICommand, so CanSaveDocument is private, it works great. If I make it public, I get the UI thread lockup. Just dont understand why...

Stop blaming CM! It's not CM that's blocking if you're using a DelegateCommand because CM isn't involved.

Since the issue also occurs when the property is public and you use a delegate command I'd say it's a weird interaction with WPF bindings, INotifyPropertyChanged and async.

@distantcam I put the delegate command in to fix the issue. DelegateCommand = working, CM = not

Who sets IsWorking, because the moment that is set is when CM will be handling the event not when you hit the await.