If you implement INotifyPropertyChanged to your Model's property, you effectively makes the Model plays the role of ViewModel. In this case, the Model wears 2 hats: while it holds business data logic, it would also works as "indirect" sub ViewModel, causing ViewModel changes with its property change.
If you want to keep clean boundary between Model and ViewModel, the logic would like:
1. user select object, so the text data is obtained to set the Model property
2. Then you need to somehow trigger OnPropertyChanged("TextToDisplay) for View to be notified the change. This is where your original code did not do.
With your original code, if you placed a break point at TextToDisplay's "set" accressor, you would have noticed the setter is never called (thus the View was not updated).
There are 2 ways to do it that are easier that implement INotifyPropertyChanged to the Model's properties (well, it might be right solution in right scenarios):
1. You do not mix the Model and the ViewModel in the ViewModel's property:
private string _textToDisplay
public string TextToDisplay
{
get=>_textToDisplay;
set
{
_textToDisplay=value;
OnPropertyChanged(nameof(TextToDisplay));
}
}
In this case, the code for the entity pick process would be like (code in a method of the ViewModel):
var pickedText=PickEntity();
if (!string.IsNullOrEmpty(pickedText) _model.OutputString=pickedText; //Model is updated
TextToDisplay=_model.OutputString; // Update the view
2. Or, you can simply do this:
// readonly ViewModelProperty
public string TextToDisplay=>_model.OutputString;
Then in the picking process, you do:
var pickedText=PickEntity();
if (!string.IsNullOrEmpty(pickedText) _model.OutputString=pickedText; //Model is updated
OnPropertyChanged(nameof(TextToDisplay); //Update view
this way, you omit the need of a private member _textToDisplay.