Why is focus in wpf so tricky

Asked 12 years, 6 months ago. Active 3 years, 3 months ago. Viewed 2k times. Improve this question. Jippers Jippers 2, 5 5 gold badges 33 33 silver badges 55 55 bronze badges. Add a comment. Active Oldest Votes. What you are likely looking for is: System. FocusedElement as FrameworkElement.

Name You will have to setup a DependencyProperty for it so that you can bind to it though. Improve this answer.

Vaccano Vaccano You could log the focus and loss-of-focus events to another place like a list control in another window. Or even set the current window title to the name of the current object with focus.

Thanks Pavan. Of course, that isn't the answer I was hoping for! Hey JG! This thread is another one to add to your "what we should simplify" list FocusedElement should get you the current element. This is a pretty manual way and not Xaml based although if you can get this working you could make it into an attached property.

Yes I tried that, but that didn't work either. It is amazing how difficult this is. It should be dead simple, in my opinion. Let me know if you figure it out I'd love to hear!

Hey, you stole my role in this thread!! It's all good, Pavan. Thanks for your help!! I found a solution, but it sucks. Can it get any more convoluted?! What if I throw in a few more controls into my TreeViewItem Sorry I'm so late to the party, Josh. That's a very awesome idea! If you can find the code, I'd love to see it. Thanks Doc! I'm there for you Seriously though, that does seem to me to be the value of patterns: you can tell somebody what the code does using fewer words.

On Jul 30, pm, "Dr. Hey John, Any chance this difficulty might be ironed out in a subsequent release of platform? It's hard to believe that creating a TreeView with checkboxes in the items, which is easy to navigate via the keyboard and mouse, requires so much custom work.

This should be dead simple, in my opinion. If it takes a Dr. WPF to figure it out, it's way too difficult! Mike Brown. Just in case anyone of is wondering how I finally implemented this hacky, ugly solution, I've attached the project. Remove the. DOC extension, and then unzip it.

What a hack! Please tell me there's a much simpler, more elegant way!! I should point out, Dr. WPF's solution is definitely more elegant , but an order of magnitude more complicated. Previously he worked for Redgate Software as a project manager and dev and is responsible for many sins. When not working he messes about with 3D printers and hitting things with hammers.

View all articles by Richard Mitchell. Federal Healthcare Managed Service Providers. Why no scrollbars? Conclusions Is WPF all bad? The default styles of ToolBar and Menu do this; there isn't any magic involved with those controls. Each focus scope stores the logical focus in the attached property FocusManager. When a control receives keyboard focus, WPF will look up its parent focus scope the nearest parent with IsFocusScope turned on and assign it to the FocusedElement property, giving the control logical focus within that scope.

Routed Commands simply execute on the main focus. Actually, now that we know what is happening, there is only a single problem to fix: we need to ensure that the main logical focus gets set. WPF only gives a control the logical focus within the nearest parent focus scope.

We will simply give it the logical focus within all parent focus scopes. But we don't want to break ToolBars and Menus.

Instead, we will implement the new focus logic as an Attached Behavior. This allows using our improved focus scope as easily as the existing: t:EnhancedFocusScope.