Vista - Bug report: (Preview)TextInput events not occuring after KeyDown

I have an non-WPF application that loads its WPF-based UI elements directly
from WPF-linked assemblies (plugins). The *supposed* advantage to this is
that, on platforms that do not support WPF, UI plugins created in Winforms
can be used as long as they implement the UI plugin interface that has been
created.

In some scenarios, text input elements (TextBox, RichTextBox, Password have
been tested) are not showing the text that is typed into them. Pasted text
appears as expected. Debugging shows that the KeyDown event is being fired
and is bubbling up the element tree to the root, but responding
PreviewTextInput events are not occuring (which, as is my understanding,
should occur when a KeyDown event has finished bubbling without having the
KeyEventArgs.Handled member set to true).

The following is a short list of scenarios that occur in the lifetime of the
application, some of which show this behavior. "Window" here refers to the
WPF Window class.

* Non-WPF-aware app "Core" is started
* "Core" loads a Window "Login", text input elements don't work
* "Core" loads a NavigationWindow "Prefs", Window "Login" loads a Page
"Accounts" into it, text elements don't work
* "Accounts" loads a Window as a Dialog, text input elements work
* That Window loads another Window as a Dialog, text input elements work
* "Core" loads a Window "Messages," text input elements don't work
* "Messages" loads a Window "Message," text input elements don't work

At one time, an attempt was made to use a custom event handler registed with
EventManager.RegisterRoutedEvent to inject text into a TextBox when the
KeyDown event was received. The Window containing the TextBox failed to
initialize when the custom RoutedEvent was created.

Click events on Buttons and MouseDoubleClick events on ListBoxes, for
example, operate as expected.

The best description I can come up with for what I'm seeing is this: The
text input elements in the dialog boxes work because they're being presented
as dialogs; the blocking Window.ShowDialog() call that presents them is
providing a solid "wall" for events to bounce from. Changing the dialog boxes
to be presented with Window.Show() results in non-functional text input
elements. As for the other windows, in a normal WPF application, there would
be an Application object at the top of the hierarchy. In the case of this
application, there is no top-level element that understands routed events
above the Window to provide returning events.

The complete codebase of this application is open source, and can be found
at https://svn.bountysource.com/shaim/ for further examination. The code, as
it existed when I first noticed the problem, is tagged in
tags/T_TextBugFound. The problem becomes immediately evident on application
launch; the Password field on the login screen does not accept input.

For the time being, I've used a Forms TextBox/RichTextBox where necessary,
but that isn't an ideal solution as it restricts many of the expressive
things I can do with WPF controls. Is there a known workaround for this
issue, or will it be addressed in future releases?

More information on this bug:


I loaded a WPF Application object into the project. This Application object
is loaded dynamically, but it provides a context for Application.Current.
All WPF windows loaded by this project recognize that the loaded Application
object is their "parent" application; resources loaded by the Application
can be used by the children, etc. However, text input events are still not
being received.