Wednesday, January 23, 2013, 02:49 PM - WPFI use the FluidMoveBehavior in .NET 4 for animating the movement of an item between two different ItemsControls. In WPF however the behavior is not always what you expect, since the item sometimes first visible ends up in the target ItemsControl before the actual animation kicks in.
This is a bug in the behavior when used in WPF and here is a workaround until fixed!
Tuesday, March 11, 2008, 06:24 PM - WPFToday I encountered the weirdest problem, when showing a WPF Window from a Windows Forms application. When writing letters and numbers into a textbox nothing happened, but space and backspace together with shortcuts for Cut, Copy and Paste worked as expected.
I first thought there must be some problem with my data template, but when showing it from a WPF application everything worked just fine. My next instant thought was that there must be some message filter, in the Windows Forms application, stealing the keyboard input.
I then created a new Windows Forms application and brought up the modeless WPF Window from there, by calling Show, only to notice the same problem. I then changed to a modal window, by calling ShowDialog instead, and suddenly everything responded as it should.
It was time to start some Google:ing…
The solution, to my big surprise, was to explicitly enable keyboard input from Windows Forms, by calling the static method ElementHost.EnableModelessKeyboardInterop. This call takes a Window as parameter and essentially registers an input hook with the Windows Forms application object, running the message loop, and calls ComponentDispatcher.RaiseThreadMessage. The call to EnableModelessKeyboardInterop can be made in the constructor, if the Window is inherited, or simply before calling the Show method.
For more information read about Sharing Message Loops Between Win32 and WPF.