Extending Controls and using FieldChanged event

Question

I am following the example from Naren's blog on "Communicating between custom controls: Building parent/child controls" and it is stated that "The event should be unhooked in the dispose of the control".  I have done this with little success in the dispose because the m_workItem is null at this point.  I am also unsure of where to actually subscribe to the event.  Where I am currently doing it is in the WorkItemDatasource set property as shown below.

 

set

{

    m_workItem = (WorkItem)value;

    if (m_workItem != null)

    {

        m_workItem.FieldChanged += new WorkItemFieldChangeEventHandler(WorkItem_FieldChanged);

        System.Diagnostics.Debug.Print("Workitem event is created");

    }

}

  

Any help on this would be appreciated. 

Thanks,

Kurt

Answer 1

I've been wondering about this too. I'll post what I've been using, and hope that Naren can tell me if it's right or wrong.

 

 

Code Snippet

set

{

 

    // if VS is unhooking the work item from the form controls

    // remove the event handler before nullifying the work item reference

    if (value == null && m_workItem != null)

    {

        m_workItem.FieldChanged -= OnFieldChangedEvent;

    }

 

    m_workItem = (WorkItem)value;

 

    if (m_workItem != null)

    { 

        m_workItem.FieldChanged += OnFieldChangedEvent; //typo fixed

    }

}

 

 I've found that using IWorkItemControl.WorkItemDatasource is a good place to subscribe and unsubscribe, and the above code works fine for me.

 

Answer 2

I looked into the source code and it seems in certain code paths we set WorkItemDataStore to null before disposing off the control. In that case jcairney's idea above works very well. I'll update my blog post to include this information. You can also  unhook in dispose event if m_workitem is not null. Thanks for pointing this out.

Answer 3

I used your method of unhooking before the value gets assigned to null and that worked nice.  Using debug it looks like it cleans up nicely, that is if I created the event it also gets unhooked when I leave the workitem.

Is it a typo on your second condition?  This is where I registered my event with "+=".

 

Kurt

Answer 4

I had tried to unhook in the dispose but I think the m_workitem is set to null before dispose is called.  Using debug the m_workitem is null when dispose is called.  I saw no condition otherwise.

 

Kurt

Answer 5

Thanks for catching that! It was a typo. That snippet wasn't directly from my code. I had to pare it down a bit. It should read as +=

 

There are some controls for which I both -= and += back to back in that if block. I have some FieldChanged event handling in a Mail-To button that appears beside several user fields in my work item, and I didn't want all of the mail buttons performing the same action all at once (e.g. sending mail to a specific user as many times as there were buttons on the form).

 

In these cases, I made the handler code static, and I unsubscribe and re-subscribe as each control loads, so only one event handler of a certain type is ever subscribed to the event at a time.

 

This is useful even without multiple controls of the same type. Even with a single control, it may appear that event handlers are being called twice if user opens a work item from Results View while the work item is also visible in the Results View viewing pane.