Bug in RadTabControl

[Moti]

Hi.
I found an issue the RadTabControl for WPF. I placed a prism region on the RadTabControl, and I did not use the region adapter the telerik offers online since I need a regular region and not an all-active region.
So the region adapter in use was prism's SelectorItemsSourceSyncBehavior.
New tabs opened as expected, but for navigation to tabs - when I resolved an already resolved view into the region, the view's tab didn't get selected.

I debugged the adapter and found out that it wasn't getting any SelectionChanged events from the control, so I tested it in a new demo app.
I added an event handler to RadTabControl.SelectionChanged and all the events did fire as expected. BUT - when I casted the control into a selector and added an event handler to ((Selector)radTab).SelectionChanged - no events fired.
Since the control actually inherits from Selector, I consider this a bug.

Eventually I just copied prism's adapter code and changed the Selector parts into RadTabControl - and it works. But I don't consider this a good solution for the long run.

Thanks, Moti.

[Hristo]

Hi Moti,

Thank you for contacting us about the issue. I am really sorry about the caused inconvenience.

Let me start by some background about the issue and I hope you will get our point in the end.
The TabControl is a control that went many refactoring procedures. Initially it was not a selector control and has its own selection changed event. This means, own event arguments and signature. Later on in its lifecycle we decided to improve the selection logic and inherited the selector control. But we already had exposed a selection API that have to stay functional without changes. Unfortunately we had no way to preserve the old event and introduce a new one. So the solution was to handle the inner selection event and re-rise it as own event preserving the legacy API.

I would like to thank you again for your feedback. Don't hesitate to contact us should you need more info.

Regards,
Hristo
Telerik

[Moti]

First of all, thank you for the reply :)

But I did not understand how keeping the legacy API (which is the one I reverted to using in my region adapter) doesn't allow you to make the selector API functional.
Worst case is when the legacy SelectionChanged event fires you also fire Selector's  SelectionChanged...
Given the information I have right now, this sounds quite possible and not complex at all.

[Hristo]

Hello Moti,

The TabControl has to handle the Selector event internally when changing the selection. It is the right way to treat the event. In other words, Selector event is fired correctly by Selector control but it is handled by the TabControl. Then TabControl fires its own SelectinoChanged event to notify the user and preserve the API.

Actually, the case is like using the Button control and trying to attach a handler to the MouseLeftButtonDown event. The MouseLeftButtonDown event is handled internally by the Button class (to perform a click action) and the event handler will not be called.
However you have the option to attach a handler that gets called by the handled events too. You could do it by using the AddHandler method and passing true for the hadnledEventsToo parameter like this:

control.AddHandler(event, handler, true)

Regards,
Hristo
Telerik

[Moti]

Actually that's a cool workaround, but I still don't get why should the control mark Selector's SelectionChanged event as handled.
I'll quote MSDN about this:

There is no absolute rule for when you should mark routed events as handled, either as an application author, or as a control author who responds to existing routed events or implements new routed events. For the most part, the concept of "handled" as carried in the routed event's event data should be used as a limited protocol for your own application's responses to the various routed events exposed in WPF APIs as well as for any custom routed events. Another way to consider the "handled" issue is that you should generally mark a routed event handled if your code responded to the routed event in a significant and relatively complete way.

According to these guidelines, the tab control should not mark the event handled, and then everything will be good.
Unless I'm missing something here?

Thanks, Moti.

[Hristo]

Hi Moti,

We are handling the event because RadTabControl performs a set of actions when Selector's SelectionChanged event is raised. In other words, RadTabControl is acting as a client for the Selector SelectionChanged event and translates it into another event (that happens to have the same name). You could think of this case as the button example (handling the MouseLeftButtonDown event and firing the Click event) which I gave you in the previous post.

MSDN also says it is decent way to treat the event:
"Another way to consider the "handled" issue is that you should generally mark a routed event handled if your code responded to the routed event in a significant and relatively complete way."

Regards,
Hristo
Telerik