CODEWITHSUNDEEP
c#wpfmvvm
Greg Mason
Greg Mason

Reputation: 803

DataContext null intermittently during events

I am having problems events raised from my viewmodel sometimes showing the datacontext as null in the view when it is serviced. I am beginning to think this is weak binding pattern issue, and that I am not using it or am misunderstanding it (rather new to design patterns in general and started WPF a couple months ago).

Relevant MainWindow.xaml

<Grid Tree:TreeView.ItemSelected="DisplayRequested"
      Tree:TreeView.PoolCategoriesChanged="PoolContentChanged">
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="200"/>
        <ColumnDefinition Width="Auto" />
        <ColumnDefinition />
    </Grid.ColumnDefinitions>
    <GridSplitter Grid.Column="0" VerticalAlignment="Stretch"/>
    <GridSplitter Grid.Column="1" VerticalAlignment="Stretch"
                  Background="Gray" ShowsPreview="True" Width="5"
                  HorizontalAlignment="Center"/>
    <GridSplitter Grid.Column="2" VerticalAlignment="Stretch"/>
    <Tree:TreeView Name="poolTree" Grid.Column="0" Focusable="True" />
    <ScrollViewer Grid.Column="2" VerticalScrollBarVisibility="Auto">
        <Details:DetailsView Name="detailsDisplay" Focusable="True"/>
    </ScrollViewer>
</Grid>

Relevant code behind

public partial class MainWindow
{
    public MainWindow()
    {
        InitializeComponent();
    }

    private void OnDataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
    {
        var vm = (CLUViewModel)e.NewValue;
        if (vm == null) return;
        vm.OwnerCleanupStarted += OnOwnerCleanupStarting;
        vm.OwnerCleanupEnded += OnOwnerCleanupEnding;
    }

    #region Event Handlers
    private void OnOwnerCleanupEnding(object sender, EventArgs e)
    {
        ViewServices.CloseProgressDialog();
    }

    private void OnOwnerCleanupStarting(object sender, EventArgs e)
    {
        var vm = DataContext as CLUViewModel;
        if (vm == null) return;
        var progressDialogViewModel = vm.ProgressDialogVM;
        ViewServices.ShowProgressDialog(GetWindow(this), progressDialogViewModel);
    }
    #endregion
}

I have several RoutedEvents that seem to function without issue. The OnOwnerCleanupStarting event seems to return null a lot on var vm = DataContext as CLUViewModel; though. Is this because it is bound too strongly and not using the WPF framework?

If I put this in debug and trace through it always works, and many times works without error during normal use. Is this a sort of race condition where I am using listeners in memory on a View that has been uninitialized when focus when to a subcomponent?

The calling logic from a VM:

public class CLUViewModel : ViewModelBase
{
    #region Properties
    private RelayCommand _manageOwnersDialogCommand;

    public ProgressDialogViewModel ProgressDialogVM;
    #endregion

    public CLUViewModel()
    {
        ProgressDialogVM = new ProgressDialogViewModel(string.Empty);
    }

    #region ManageOwnersDialogCommand
    public ICommand ManageOwnersDialogCommand
    {
        get
        {
            return _manageOwnersDialogCommand ??
                   (_manageOwnersDialogCommand = new RelayCommand(param => OnManageOwnersDialogShow()));
        }
    }

    private void OnManageOwnersDialogShow()
    {
        var dialog = new ManageOwnersDialog();
        var vm = new ManageOwnersViewModel();
        dialog.DataContext = vm;

        if (!dialog.ShowDialog().Value) return;

        var ownersRequiringCleanup = GetOwnersRequiringCleanup(vm);

        if(ownersRequiringCleanup.Count < 1) return;

        ProgressDialogVM.ClearViewModel();
        ProgressDialogVM.TokenSource = new CancellationTokenSource();
        ProgressDialogVM.ProgressMax = ownersRequiringCleanup.Count*2;

        RaiseOwnerCleanupStartedEvent();

        var taskOne = Task.Factory.StartNew(() => OwnerCleanupService.DoOwnerCleanup(ownersRequiringCleanup, ProgressDialogVM));

        taskOne.ContinueWith(t => RaiseOwnerCleanupEndedEvent(), TaskScheduler.FromCurrentSynchronizationContext());
    }

    private List<Owner> GetOwnersRequiringCleanup(ManageOwnersViewModel vm)
    {
        var ownersRequiringCleanup = new List<Owner>();

        // using DB to determine cleanup
        // Proprietary code removed for this discussion

        return ownersRequiringCleanup;
    }
    #endregion

    #region Events
    public event EventHandler OwnerCleanupStarted;
    public event EventHandler OwnerCleanupEnded;

    public void RaiseOwnerCleanupStartedEvent()
    {
        if (OwnerCleanupStarted == null) return;            
        OwnerCleanupStarted(this, new EventArgs());
    }

    public void RaiseOwnerCleanupEndedEvent()
    {
        if (OwnerCleanupEnded == null) return;
        OwnerCleanupEnded(this, new EventArgs());
    }
    #endregion
}

I have this same problem with several other controls where their various VMs make calls to Parents (within a treeview) and that parent raises the event.

I have been learning this as I go along, and some of the Events I used form the VM side was my earlier understanding of how things work. Is this where I should have called an event that raised to to my View that then starts a RountedEvent to Bubble to the appropriate level? Did I fall into a trap of strong binding vs. weak binding?

EDIT: Solved Parent/Children TreeView issue being seen. Master-Detail pattern meant I had been accessing detail Views which were not visible or never were loaded. Initial question now is still getting occurrences of null. Is there a better way to call back from VM to View for UI related issues that won't have difficulty with View DataContext?

Upvotes: 3

Views: 597

Answers (1)

Fede
Fede

Reputation: 44028

I would recommend against event-based programming models in WPF. because it's just too easy to get into things like this. And event-based programming forces tight coupling. so its a double no-no

Instead of throwing an event in the View, use a DelegateCommand to execute actions defined in the ViewModel level, and instead of throwing events in the ViewModel, just use regular properties and INotifyPropertyChanged to represent the state of things.

This certainly requires a significant mindshift from the winforms or anything else non-wpf way of thinking, but when you realize it, you produce less and cleaner code.

Upvotes: 2

Related Questions