Don't do it that way. Do it in a viewmodel-centric way instead: Make the NoteListingVM a property of the parent viewmodel.

Instead of structuring your application as a tree of views which own viewmodels that struggle to know what they need to about each other, make it a tree of viewmodels that own their own relationships. Festoon them with views that don't need to know about anything but their own viewmodels.

Note that the InvoiceID property below updates Notes.InvoiceID when it changes. Easy as pie.

public MyViewModel() { Notes = new NoteListingVM(); } private int _invoiceID = 0; public int InvoiceID { get { return _invoiceID; } set { if (value != _invoiceID) { _invoiceID = value; Notes.InvoiceID = this.InvoiceID; OnPropertyChanged(); } } } private NoteListingVM _notes = null; public NoteListingVM Notes { get { return _notes; } protected set { if (value != _notes) { _notes = value; OnPropertyChanged(); } } } 

XAML. You could wrap a DockPanel around the ContentControl if you want.

<Expander Header="NOTES" DockPanel.Dock="Top" Foreground="{StaticResource AlternateForeGround}" > <ContentControl Content="{Binding Notes}" /> </Expander> 

Alternate

You could also write a NotesView UserControl that has an InvoiceID dependency property, and bind that in the XAML. It would use the same NoteListingVM; you'd assign that via the DataContext property just as you've been doing. The user control's InvoiceID dependency property would have a change handler that updates the viewmodel's InvoiceID, which would let you use a binding to set the InvoiceID. That's a "proper XAML" way to do what you originally had in mind.

You could also entirely rewrite NoteListingVM as a UserControl, but that's more work and I don't see a whole lot of point to it.

You don't mix viewmodel/INotifyPropertyChanged properties with dependency properties in the same class.