ComboBox.DataContext triggers SelectionChanged on parent TabControl??

Question

 

If I set a child ComboBox.DataContext to a DataSet, it triggers the Parent TabControl.SelectionChanged event??  Anyone know why this happens?  It really should NOT be the case.

 

Is this a bug in WPF?

Answer 1

yes, this does happens.

there are two solutions of top of my head:

check sender == e.originalsource

or, on checkbox selection changed set e.Handled = true

Answer 2

 

Thank you, yes I'm working around it by checking e.Source.  But am I correct this is a bug?  I would find it difficult to believe this is "by design"?  Changing the value in a child combobox does NOT change the selection in a TabControl so this even should not fired.

 

If this is indeed a bug, any word on when/if Microsoft plan to fix this - SP?

 

Thanks, Rob.

Answer 3

This is because both ComboBox and TabControl are derived from Selector, and the SelectionChanged event is a routed event, so the child ComboBox' SelectionChanged event will be routed to its parent control TabControl. Just like mouse event can be routed from a child element to its parent element. This is the WPF routed event behaviour. We should always notice this behaviour when we playing with WPF.

 

Best Regards,

Wei Zhou

Answer 4

 

But Tab selection has not changed?  That's the reality.

 

If I'm to proceed down your path of logic, then any mouse click anywhere could be deemed as a "selector" and possible parent.  Isn't the entire point of handling events specific to a control to filter out the relevant from the not relevant events?

 

The routed event behaviour isn't really a behaviour, it's a lack on correct event filtering in the WPF Tab control.

 

Unfortunately when you use terms like "playing with WPF" -- I'm beginning see why you use such a term, WPF feels very "unfinished", some cool stuff in WPF, but for the most part not entirely thought out very well and it feels like the WPF dev team just "stopped" with an incomplete tool.

Answer 5

The routed event bubble routing is accroding to the logical tree, if you put a ComboBox in a TabItem of a TabControl, when the ComboBox.SelectionChanged event raised, the event will be routed to the TabControl. But, if the ComboBox is not in the logical tree of TabControl, then the event will not be routed to the TabControl. For more information about logical tree and routed event, you can refer to the following links.

http://msdn2.microsoft.com/en-us/library/ms750605.aspx

http://msdn2.microsoft.com/en-us/library/ms753115.aspx

 

Best Regards,

Wei Zhou

Answer 6

 

Wei,

 

The discussion is going no where, obviously you aren't getting what I'm saying.

 

I click on a ComboBox -- the TabControl SelectionChanged event should NOT be triggered regardless of the logic tree -- again you need to separate out Microsoft's fantasy land with reality.

 

If I wanted the TabControl SelectionChanged to respond to ComboBox SelectionChanged event, I'd simply add a handler for it as needed.  With the WPF approach, I HAVE TO ALWAYS write event filter code for any control contained in it.  Now I ask you, which is better for the developer?  When the developer has to write less code, not more code -- that is the correct answer.

 

Sorry if I sound frustrated, but Microsoft seem to moving more and more into some fantasy land where Red is Blue and Large is Small.  I find this a disturbing trend at Microsoft, one I encounter day in and day out.

Answer 7

Rob,

I believe that if you set the Handled flag to true in the ComboBox's event handler, then the tab control should not see the event. It's possible to override this, but the Tab Control has to actually do this. (At least, that's what I get from WPF Unleashed, page 70.) If this is the behavior that you're seeing, you should look for an added event handler for the tab where the HandledEventsToo is set to true.

 

Wei,

Your answer, while technically correct, is useless. There is no reason for the tab control to care about the ComboBox's contents changing. RTFM is not a constructive answer.

 

Answer 8

 

Mike,

 

Thanks, I'll look into that approach also -- I was hoping there would be a ComboBox property I could set so that this event would NOT follow the "logic tree".

 

But my bigger issue is that I hope Microsoft understand why a RAD developer wants tools that reflect reality and help get them from A to B as fast as possible.  There are two issues going on here:

 

1.  In the real world this logic makes NO sense

2.  This bizarre "logic tree" implementation forces the developer to visit places like this and do R&D

3.  The developer has to work "around" (aka add code) the problem

 

Working with WPF under VS 2008 and I encounter 1,2,3 daily -- this isn't a good thing for me.  I appreciate the WPF team has but a lot of work into this tool, but it needs to solve real world problems if Microsoft want developers to adopt it.  As it stands now, I've got BitMap effects I have to use VERY sparingly since there is no hardware acceleration support, a "logic tree" that is brain dead, need to use Expression Blend (separate product) to efficiently build the WPF XAML code, then use that XAML with some minor modifications in my VS 2008 project.  Toss in the mix what appears to be random reloads of XAML windows in VS 2008 which are painfully slow in design time.  And lets not even start to talk about 64bit -- there is an entire world of problems around that (no OLEDB support, no Edit and Continue support, etc. -- not WPF specific).

 

Anyway, I digress, but I would like to see Microsoft build better integrated development tools rather than just starting new technology for the sake of it and only going about 70% distance on the new technology.  Doesn't Microsoft see the big picture here?

 

 

 

 

Answer 9

Rob,

Microsoft is about "variety" and not about "big picture". They never were about "big picture", may be Ray Ozzie will change it, because he seemed to know how to handle the complexity of Microsoft offerings.
So when you try to race to have more of the "variety" you tend to miss on quality, because it is hard for the people in general to deal with massive amount of information. Thus even within Microsoft many people can not handle such massive information flow and miss big picture.

Take a look at other technology companies. Whenever you see less offerings you would usually see better quality, such as Google and Apple.
So it is your pick, do you want to have MORE of the so-so tools, or have very few but excellent tools? Either way it is a struggle for end-developer :). I can't just go and do everything I am doing using Google tools, or Apple tools. The spectrum of my work is too broad for me to know in-depth details of various technologies, so I myself would not be able to produce a good quality work in some areas. So I picked Microsoft. When I was on Linux and Java, I had to deal with other issues myself, which now are somewhat (your 70%) handled by Microsoft.

Take care.