0

Why would clicking in another TextBox not raise the LostFocus event of the current (bound) TextBox and thereby commit changes to the data source? My UpdateSourceTrigger is not set, so I assume that by default WPF would commit changes on LostFocus.

My changes get committed correctly when I do the same thing using TAB key instead of mouse click.

EDIT

I just found out that clicking on TextBoxes that appear in the same parent container DOES raise LostFocus and commits changes, but when I click a TextBox that lives in the main ToolBar of my screen, then it seems to show this problemetic behavior.

EDIT 2

Although I have marked BastiOnWpf's post as the correct answer below, I found an equally good or better solution to fix this problem. The solution is to simply set 

FocusManager.IsFocusScope="False"

on your ToolBar in XAML.

dotNET
  • 33,414
  • 24
  • 162
  • 251
  • did you use FocusManager in any way in your view? – blindmeis Mar 28 '13 at 08:14
  • @blindmeis: Yes, but only to set initial focus to a specific element upon loading. Also, see my edit above. – dotNET Mar 28 '13 at 08:59
  • Does this answer your question? [Binding with UpdateSourceTrigger==LostFocus do not fire for Menu or Toolbar interaction](https://stackoverflow.com/questions/5631243/binding-with-updatesourcetrigger-lostfocus-do-not-fire-for-menu-or-toolbar-inte) – Peter Duniho Jul 17 '20 at 17:08

1 Answers1

0

The problem is that the Textbox actually does, in fact, not lose focus, when the menu or its contents is clicked/focused. This is because the Toolbar resides in another UIContext.

You could of course change the UpdateSourceTrigger to PropertyChanged, but that isn't always a feasible workaround:

Here are some approaches to fix the problem: Binding with UpdateSourceTrigger==LostFocus do not fire for Menu or Toolbar interaction

This is also the reason why binding the toolbar to the ViewModel of the current UI does not work.

Community
  • 1
  • 1
Basti
  • 994
  • 6
  • 11
  • Thanks man. This was precisely the problem, though I found a different and IMO simpler solution to fix this behavior. I have posted my solution on the page you mentioned above, just to help future readers find it all in one place. I'll mark it your post as answer though, because it DOES solve the problem in general. – dotNET Mar 28 '13 at 11:33
  • That is a neat solution. Much cleaner than those other ones. – Basti Mar 28 '13 at 12:49