帮助处理 WPF TextCompositionManager 事件
这方面的文档非常粗制滥造。 您可以挂钩许多事件来监视和控制通过 TextCompositionManager 访问的文本输入。 如果您想要执行诸如获取卡刷卡数据之类的操作，那么您可以在此处执行此操作。
共有三个事件涉及文本输入：TextInput、TextStart 和 TextUpdate。 每个事件有两种版本，一种是事件隧道（从窗口向下移动到具有焦点的控件），另一种是冒泡（从窗口向上移动）焦点 UI 元素到窗口）：
隧道：
- PreviewTextInputEvent
- PreviewTextInputStartEvent
- PreviewTextInputUpdateEvent
冒泡：
- TextInputEvent
- TextInputStartEvent
- TextInputUpdateEvent
因此，根据您挂接到 TextCompositionManager 的逻辑树中的位置，您可以修改这些文本事件在到达事件焦点之前，或者只是在之后查看它们。 所有这些在文档和使用中都非常简单明了。
TL;DR
我找不到这三个事件的合适定义。 可接受的答案不仅会定义三个事件（TextInput、TextInputStart 和 TextInputUpdate），还会对它们进行比较和对比。 不分享答案，请参考您的来源，维基百科是禁止的。 你25%的成绩取决于此。
The docs on this are pretty shoddy. There are a number of events you can hook into to monitor and take control of text input that are accessed via the TextCompositionManager. If you're wanting to do something like snag card swipe data, this is where you'd do it.
There are three events that concern text input: TextInput, TextStart, and TextUpdate. There are two versions of each event, one where the event is tunneling (traveling down from the Window to the control which has focus) and when it is bubbling (traveling up from the focused UI element to the window):
Tunneling:
- PreviewTextInputEvent
- PreviewTextInputStartEvent
- PreviewTextInputUpdateEvent
Bubbling:
- TextInputEvent
- TextInputStartEvent
- TextInputUpdateEvent
So, depending where in the logical tree you hook into the TextCompositionManager, you can modify these text events before they get to the focus of the event, or just view them afterwards. All this is pretty simple and clear in the docs and in use.
TL;DR
I can't find a decent definition of the three events. An acceptable answer will not only define the three events (TextInput, TextInputStart, and TextInputUpdate), but also will compare and contrast them. No sharing of answers, please reference your sources and Wikipedia is off limits. 25% of your grade depends on this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它们之间的差异取决于您输入的字符类型。
请注意，像 Shift 和 Ctrl 这样的修饰键不会直接触发这些事件（与 KeyDown 不同，在 KeyDown 中您会看到先按下 Shift，然后再按下 5，等等）。 例如，若要获取“%”，Shift+5 只会生成一系列事件（即，一个 TextInputStart 和一个 TextInput），并且两者都接收字符串“%”。
每当您开始输入字符或字符代码时，都会触发 TextInputStart。 当您按下标准键、控制键或十进制键代码的第一位时，它会被触发。 当它被触发时，系统有时（但并非总是）已经知道您按下的键（如标准键和控制键的情况）。 如果它知道，它会在 TextCompositionEventArgs 中告诉你； 如果它不知道，则 TextCompositionEventArgs 为空并且什么也不告诉您。
当您输入十进制键代码的第二个及后续数字时，将触发 TextInputUpdate。 除了此事件的空 TextCompositionEventArgs 之外，我还没有看到任何内容（尽管这可能会因死键或 IME 而改变）。
输入完密钥后，将触发 TextInput，并且系统确切地知道您输入的密钥，因此 TextCompositionEventArgs 中始终包含有用的信息。 此事件意味着该字符现在实际上正在“键入”（即，它对应于如果您在文本框中键入该字符的时间）。
以下是事件序列对于不同类型字符的工作方式：
标准键：只要按下该键，您就会立即获得一个 TextInputStart，后跟一个 TextInput。 两者的 TextCompositionEventArgs 中具有相同的内容：e.Text 和 e.TextComposition.Text 均设置为您按下的键。 （请注意，这并不总是可打印的字符。如果按 Backspace，它就会在 e.Text 中。）如果按住该键，则每次按键重复都会获得一对事件 (TextInputStart/TextInput)。
控制键：只要按下字母键，您就会立即得到一个 TextInputStart，后跟一个 TextInput。 两者的 TextCompositionEventArgs 中具有相同的内容：e.ControlText 和 e.TextComposition.ControlText 均设置为您按下的控制键。 如果按住字母键，则每次重复按键都会获得一对事件 (TextInputStart/TextInput)。
十进制键代码：假设您正在输入 Alt+小键盘 0 2 5 5。一旦您按下小键盘 0，您就会收到一个 TextInputStart 事件，该事件绝对不会告诉您任何有用的信息。 对于每次击键小键盘 2、小键盘 5 和小键盘 5，您都会收到一个 TextInputUpdate 事件，同样没有有用的信息（您无法判断到目前为止按下了哪些数字）。 当您释放 Alt 键（实际上“键入”您输入的代码的键）时，您将收到 TextInput 事件，以及您在 e.Text 和 e.TextComposition.Text 属性中输入的键。 （这可能是不可打印的字符，例如，如果您输入 Alt+小键盘 0 8。） 对于十进制键代码，无法进行按键重复。
死键：正如我上面提到的，我不知道如何测试它。 如果有人有答案，请告诉我，我会将其包含在这里。
IME：同样，我不知道如何测试它。
我的印象是，对于大多数用途来说，TextInput 是这些事件中唯一一个有意义的使用（因为其他两个并不总是告诉您任何信息）。 这可能就是为什么它是三个中唯一一个在 UIElement、UIElement3D 和 ContentElement 上重新公开为标准路由（非附加）事件的原因。
The differences between them depend on what type of character you're typing.
Note that modifier keys like Shift and Ctrl do not fire these events directly (unlike KeyDown where you see the Shift being pressed, then the 5 being pressed, etc). For example, Shift+5, to get "%", only generates one sequence of events (i.e., one TextInputStart and one TextInput), with both receiving the string "%".
TextInputStart is fired whenever you begin typing a character or character code. It's fired when you press a standard key, a control key, or the first digit of a decimal key code. When this is fired, the system sometimes, but not always, already knows what key you're pressing (as in the case of standard keys and control keys). If it knows, it will tell you in the TextCompositionEventArgs; if it doesn't know, the TextCompositionEventArgs is empty and tells you nothing at all.
TextInputUpdate is fired when you enter the second and subsequent digits of a decimal key code. I have yet to see anything but an empty TextCompositionEventArgs for this event (though it's possible that that changes with dead keys or IMEs).
TextInput is fired when you're done entering the key, and the system knows for sure what key you entered, so it always has useful information in the TextCompositionEventArgs. This event means the character is actually being "typed" now (i.e. it corresponds to when the character would show up if you were typing into a TextBox).
So here's how the sequences of events work for different types of characters:
Standard key: As soon as you press the key, you get a TextInputStart immediately followed by a TextInput. Both have the same content in their TextCompositionEventArgs: e.Text and e.TextComposition.Text are both set to the key you pressed. (Note that this is not always a printable character. If you press Backspace, it's in e.Text.) If the key is held down, you get the pair of events (TextInputStart/TextInput) for each key-repeat.
Control key: As soon as you press the letter key, you get a TextInputStart immediately followed by a TextInput. Both have the same content in their TextCompositionEventArgs: e.ControlText and e.TextComposition.ControlText are both set to the control key you pressed. If the letter key is held down, you get the pair of events (TextInputStart/TextInput) for each key-repeat.
Decimal key code: Let's say you're typing Alt+numpad 0 2 5 5. As soon as you press numpad 0, you get a TextInputStart event, which tells you absolutely nothing useful. For each of the keystrokes numpad 2, numpad 5, and numpad 5, you get a TextInputUpdate event, again with no useful information (you can't tell what digits have been pressed so far). When you release the Alt key (which actually "types" the key whose code you entered), then you get the TextInput event, with the key you entered in the e.Text and e.TextComposition.Text properties. (This may be a nonprintable character, e.g. if you entered Alt+numpad 0 8.) Key-repeat isn't possible for decimal key codes.
Dead key: As I mentioned above, I don't know how to test this. If anyone has the answer, let me know, and I'll include it here.
IME: Again, I don't know how to test this.
My impression is that, for most uses, TextInput is the only one of these events that it makes sense to use (since the other two don't always tell you anything). That's probably why it's the only one of the three that's re-exposed as a standard routed (non-attached) event on UIElement, UIElement3D, and ContentElement.