Hi Naftis,

At present, Ihave no ideas withthe suggested way of this scenario. But as in my view, you can add the code which needs user interaction at last. Whentesting the OpenFile command method, we canpass theFileName to the method from test method. And after we assure the logic has no problems, we can then add the interaction code.

As an alternative, as you said, we can handle the button click event and add the code to open a file dialog. After that, we can pass the opened filename to the command through CommandParameter. In case you need, I just wrote the following code for your reference.

Xaml code:

                <MenuItem Command="{Binding ReadmeCommand}" Header="Readme" Click="MenuItem_Click">
                    <MenuItem.CommandParameter>
                        <Binding Source="{StaticResource data}" Path="FileName" Mode="TwoWay"></Binding>
                    </MenuItem.CommandParameter>
                </MenuItem>

C# code:

    public partial class MainView : Window
    {


        CommandData data;
        public MainView()
        {
            InitializeComponent();
            data = this.FindResource("data") as CommandData;
 
        }

        private void MenuItem_Click(object sender, RoutedEventArgs e)
        {
            OpenFileDialog dialog = new OpenFileDialog();
            if (dialog.ShowDialog() == true)
            {
                data.FileName = dialog.FileName;
            }
                
        }
    }
    public class CommandData:INotifyPropertyChanged 
    {
        private string fileName;

        public string FileName
        {
            get
            {
                return fileName;
            }
            set
            {

                fileName = value;
                if (null != this.PropertyChanged)
                {
                    PropertyChanged(this, new PropertyChangedEventArgs("FileName"));
                }
            }
        }

        #region INotifyPropertyChanged Members
        public event PropertyChangedEventHandler PropertyChanged;
        #endregion
 
    }

If you have any problems with this, please feel free to let me know.


Best regards,
Bruce Zhou

Hi Naftis,

The problem comes to youdue tothe requirement thattest can't be blocked by user interaction. As before, I thinksuch kind of code can be added at last.For example, exception handling, we can log the exception into a file instead of displaying a messagebox in the test phase, and after all test passed, we can replace the log code with message box popup code.


Best regards,
Bruce Zhou

Thanks guys! This gives me different options, even if all require some "trick", but it's useful to know that I'm not missing something capital in my learning of this pattern. At any rate, as for your suggestions, such things (dialogs or exception messages) would be placed in the VM (either as conditional code or as Gareth suggests), not in the view, and this would be fine for allowing us to directly link user interface controls to VM commands without "polluting" the view with code behind.
Anyway, displaying e.g. a message box or a dialog from the VM seems to me (but maybe I'm just misunderstanding) somewhat a pattern-breaker, as I was inclined to think the VM as a totally view-agnostic, UI-less presenter layer; of course, the alternative is breaking the direct V-VM connection via binding and add some code behind in the view, but I don't know which would be "best" (or maybe it's just a matter of taste). Apart from this generic issue, I might find problems in using UI pieces in the VM: say for instance I must center a dialog in the owner window: in code behind I just set the Window's Owner property= this (or use a GetWindow(this) if it's a user control), but of course in a VM there is no reference to the view and thus no notion of the owner window. This would be another reason to add some code behind in the view, rather than coding in the VM. Anyway, thanks to all for the discussion, this allows newbies like me to have some more understanding of this pattern!