0

so I have a control whose panel attaches these events inside the panel's initialized event:

  gvvm = DataContext as GraphViewerViewModel;
  gvvm.ZoomToFitEvent += new EventHandler(_GraphViewerViewModel_ZoomToFitEvent);
  gvvm.ZoomInEvent += new EventHandler(_GraphViewerViewModel_ZoomInEvent);
  gvvm.ZoomOutEvent += new EventHandler(_GraphViewerViewModel_ZoomOutEvent);
  gvvm.CloseVCDEvent += new EventHandler(gvvm_CloseVCDEvent);
  gvvm.LoadVCDEvent += new EventHandler(gvvm_LoadVCDEvent);
  gvvm.ScrollToTimeEvent += new EventHandler<GraphViewerViewModel.ScrollToTimeEventArgs>(gvvm_ScrollToTimeEvent);

Question 1. When should I detach the events? Is is appropriate to do so in panel.unloaded?

question 2. Is it appropriate to use events to communicate from your view model to your view? it seemed more reasonable than creating a property bool and doing actions in the panel based on the propertychanged event, though that has the advantage of not requiring me to subscribe/unsubscribe events. But the downside is I have to think of reasonable names for a property event toggle.

Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
James Joshua Street
  • 3,259
  • 10
  • 42
  • 80
  • You should do some reading on [MVVM](http://stackoverflow.com/questions/1405739/mvvm-tutorial-from-start-to-finish) that will help answer your second question. This is important to know if you are working with WPF. – Bernard Feb 11 '14 at 20:25
  • Not related to your question, but you might want to check if `gvvm` is null before using it. If the `DataContext` isn't a `GraphViewerViewModel` you'll get an exception. Also, those events sure look view related, not viewmodel related (Zoom). Try to find a way to let the user zoom around without anything happening at all in the viewmodel. – Steve Feb 11 '14 at 21:18

1 Answers1

1

Answer to question #1 is yeaaahhh, kinda, Unloaded event should serve for releasing resources.

However if the event handler is living only inside the control and you know that the control is not gonna be added or removed from VisualTree constantly during runtime then you could let the garbage collector do the job for you. Means once nobody holds the instance to your control the garbage collector will collect all of it anyways.

Answer to question #2: Read what Bernard said. The communication between View and ViewModel should not exist. However the ViewModel may communicate with the View which is the case everytime you set a Binding or you use INotifyPropertyChanged interface.

dev hedgehog
  • 8,698
  • 3
  • 28
  • 55
  • agree on answer to Q#2. Such event subscribing beats the purpose of MVVM assuming OP is trying to apply MVVM because the variable naming. – treehouse Feb 11 '14 at 20:34
  • Note: The answer to #1 holds so long as this view always has the same view model. If the DataContext changes, then Unloaded is not sufficient. Sadly, after .NET 4.5.1, you can't always count on DataContextChanged, either. – Rob Ocel Feb 11 '14 at 20:35
  • Dear Street you could always implement a weak event manager in your control and you wouldnt worry about unsubsribing. – dev hedgehog Feb 11 '14 at 20:39
  • yeah, i was considering using a weak event manager. time to google and try it i guess. was just curious whether using unloaded would be sufficient or not. Also, I don't really understand the answer to question #2. I thought the view can know the viewmodel but the viewmodel cannot know the view. I don't see how creating an event within the view model that the view can attach to is any different than having some property that the view binds to. – James Joshua Street Feb 11 '14 at 21:16
  • Events owned by ViewModel such as PropertyChanged are allowed in MVVM. But they are rare. Binding is binding and it does its usual bread. Binding may be two way or one way to source or whatever. The answer to the question if Unload is efficient. Yes it is. Onload should do fine and OnDataContextChanged should also do fine. – dev hedgehog Feb 11 '14 at 21:19