.NET Framework Developer Center >
.NET Development Forums
>
Windows Presentation Foundation (WPF)
>
RoutedEvent.AddOwner question
RoutedEvent.AddOwner question
- Hi
Why is it that the argument to AddOwner sometimes is not the same type as the class where the RoutedEvent is defined. Please see below, CalendarDay is set as the owner whereas the RoutedEvent is defined in Calendar Class. I don't understand the purpose of this. This code is taken from a sample project that I study.
http://www.codeproject.com/KB/WPF/WPFOutlookCalendar.aspx
Thanks, see code below or project above for more info.
public class Calendar : Control { public static readonly RoutedEvent AddAppointmentEvent = CalendarTimeslotItem.AddAppointmentEvent.AddOwner(typeof(<strong>CalendarDay</strong>)); // J : The traditional event wrapper. public event RoutedEventHandler AddAppointment { add { AddHandler(AddAppointmentEvent, value); } remove { RemoveHandler(AddAppointmentEvent, value); } }
Best regards Jesper Odgaard Nielsen
Answers
- Sorry, can't explain it.I had a look at the source code though, and personally I don't like the duplication of the AddAppointmentEvent. He could have added a handler to the CalendarTimeslotItem.AddAppointmentEvent just as well. The only reason I can think of is that it's easier for the consumer of the Calendar control to not be bothered with the inner workings of it. But then it could also have been done the other way around: define the event on the Calendar class and add a static helper method to be able to raise the event from the CalendarTimeslotItem.hth,Marcel
- Marked As Answer byJesper Odgaard Nielsen Wednesday, July 08, 2009 8:01 AM
All Replies
- I also don't think this is correct. It should be of type Calendar. Can it be a copy/paste error from CalendarDay?PS: I added a question to the CodeProject article about this...hth,Marcel
- Edited byDutchMarcel Wednesday, July 01, 2009 7:42 AMAdded PS
- Thanks Marcel, I also suspect that it could be an error, and that he actually meant Calendar. Thanks for looking at it :-). However, if you put a breakpoint in the traditional event handler assignment.....
public event RoutedEventHandler AddAppointment
{
add <- Breakpoint here!!
{
AddHandler(AddAppointmentEvent, value);
}
remove
{
RemoveHandler(AddAppointmentEvent, value);
}
}
... and then run the it in debug mode, this line will only get 'breaked' if you have CalendarDay and not Calendar. But in either case the program runs fine, moreover, I found out that I can put a lot of other class definitions in the line below. e.g.:
CalendarTimeslotItem
.AddAppointmentEvent.AddOwner(typeof(UIElement));
.. and it still works fine. Im somewhat confused I must confess. Any oppinion on this?
Best regards Jesper Odgaard Nielsen - I know you can (ab)use it in combination with the Inherits metadata option. In that case it can be helpful to specify a baseclass if you want it to inherit down the tree over multiple types of elements. I'm not sure if that is recommended usage, I would probably go for an attached property in such a case.Personally I have never seen the need for specifying anything other than the class it is defined in.hth,Marcel
- Edited byDutchMarcel Wednesday, July 01, 2009 9:31 AMtypo
- Thanks Marcel,
I can understand that you mean that the typeof(Calendar) should be the right class to use. However, can you explain why I don't get a break in debug when using Calendar, and I get a break when I use CalendarDay?
Jesper.
Best regards Jesper Odgaard Nielsen - Sorry, can't explain it.I had a look at the source code though, and personally I don't like the duplication of the AddAppointmentEvent. He could have added a handler to the CalendarTimeslotItem.AddAppointmentEvent just as well. The only reason I can think of is that it's easier for the consumer of the Calendar control to not be bothered with the inner workings of it. But then it could also have been done the other way around: define the event on the Calendar class and add a static helper method to be able to raise the event from the CalendarTimeslotItem.hth,Marcel
- Marked As Answer byJesper Odgaard Nielsen Wednesday, July 08, 2009 8:01 AM
Sorry, can't explain it.
I had a look at the source code though, and personally I don't like the duplication of the AddAppointmentEvent. He could have added a handler to the CalendarTimeslotItem.AddAppointmentEvent just as well. The only reason I can think of is that it's easier for the consumer of the Calendar control to not be bothered with the inner workings of it. But then it could also have been done the other way around: define the event on the Calendar class and add a static helper method to be able to raise the event from the CalendarTimeslotItem.hth,Marcel
Thaks Marcel.
Best regards Jesper Odgaard Nielsen

