TSF ITfTextEditSink::OnEndEdit observes direct ASCII edits in Packaged Notepad, but not in Win32 EDIT or RichEdit — is this expected behavior? Details

Hello,

I am developing a Windows text input support application using the Text Services Framework (TSF), and I would like to clarify the expected behavior of ITfTextEditSink::OnEndEdit / ITfEditRecord for direct ASCII input.

At this stage, the implementation is read-only for diagnostics. It does not modify text.

The purpose of this test is to detect a shortcut such as:

when the user types it directly from the hardware keyboard, without creating an IME composition.

The user should be able to keep Microsoft IME as the normal input method. We do not want to require the user to switch input profiles just to use the shortcut feature.

Test environment

• Windows 11 x64
• TSF text service
• ITfTextEditSink
• ITfEditRecord
• No SetText
• No clipboard operations
• No SendInput
• No keyboard hook
• No simulated Backspace/retyping
• No polling-based text monitoring

The text service is successfully activated and the document context / text edit sink is attached before the test.

Test procedure

The initial text is:

The caret is placed immediately after 。 and before the ASCII space.

The user then types the following directly from the keyboard:

The expected final text is:

Result 1: Packaged Notepad

With the current Windows Notepad application, the TSF diagnostic path successfully observes the direct ASCII edits.

We receive text edit observations corresponding to:

After the final l, we can read the text immediately before the caret and reconstruct the exact shortcut range /mail.

No IME composition is involved.

So in Packaged Notepad, this read-only detection method works.

Result 2: Standard Win32 EDIT control

We created a minimal Win32 test application containing a standard Unicode EDIT control.

The following conditions are confirmed:

• the TSF text service is activated;
• the host is accepted by the diagnostic text service;
• the context is attached;
• the text edit sink setup succeeds;
• the control has focus;
• the final text is correctly changed by the user's keyboard input to:

However, during the direct ASCII /mail input interval, our OnEndEdit / ITfEditRecord diagnostic path produces no committed-text edit observation.

The text is visibly inserted into the control, but the edit is not observable through the same TSF path that works in Packaged Notepad.

Result 3: RichEdit

We repeated the same test using:

The result is the same as with the standard EDIT control:

• TSF service activation succeeds;
• context/sink attachment succeeds;
• focus remains on the RichEdit control;
• the final text is correctly:

but the direct ASCII insertion produces no committed-text edit observation through our current ITfTextEditSink / ITfEditRecord diagnostic path.

Questions

Is this host-dependent behavior expected by TSF design?

In particular, is a TSF text service guaranteed to receive ITfTextEditSink::OnEndEdit notifications for direct committed ASCII edits in standard Win32 EDIT and RichEdit controls when no TSF composition is active?

1. If such notifications are not guaranteed, what is the Microsoft-recommended supported architecture for observing direct keyboard text input such as /mail across Windows edit controls?
2. Is there a supported TSF architecture that allows this while the user continues to use Microsoft IME as the active input method, without requiring the user to manually switch to another input profile?

We specifically want to avoid unsupported or intrusive approaches such as keyboard hooks, clipboard monitoring, SendInput, or simulated deletion/retyping.

At this point, we are trying to determine whether the difference between Packaged Notepad and standard EDIT/RichEdit is:

• expected TSF behavior;
• a limitation of this observation approach; or
• an indication that our TSF integration for these controls is incomplete.

Any clarification on the expected TSF behavior, or guidance toward the appropriate supported architecture, would be greatly appreciated.

Thank you.Hello,

I am developing a Windows text input support application using the Text Services Framework (TSF), and I would like to clarify the expected behavior of ITfTextEditSink::OnEndEdit / ITfEditRecord for direct ASCII input.

At this stage, the implementation is read-only for diagnostics. It does not modify text.

The purpose of this test is to detect a shortcut such as:

when the user types it directly from the hardware keyboard, without creating an IME composition.

The user should be able to keep Microsoft IME as the normal input method. We do not want to require the user to switch input profiles just to use the shortcut feature.

Test environment

• Windows 11 x64
• TSF text service
• ITfTextEditSink
• ITfEditRecord
• No SetText
• No clipboard operations
• No SendInput
• No keyboard hook
• No simulated Backspace/retyping
• No polling-based text monitoring

The text service is successfully activated and the document context / text edit sink is attached before the test.

Test procedure

The initial text is:

The caret is placed immediately after 。 and before the ASCII space.

The user then types the following directly from the keyboard:

The expected final text is:

Result 1: Packaged Notepad

With the current Windows Notepad application, the TSF diagnostic path successfully observes the direct ASCII edits.

We receive text edit observations corresponding to:

After the final l, we can read the text immediately before the caret and reconstruct the exact shortcut range /mail.

No IME composition is involved.

So in Packaged Notepad, this read-only detection method works.

Result 2: Standard Win32 EDIT control

We created a minimal Win32 test application containing a standard Unicode EDIT control.

The following conditions are confirmed:

• the TSF text service is activated;
• the host is accepted by the diagnostic text service;
• the context is attached;
• the text edit sink setup succeeds;
• the control has focus;
• the final text is correctly changed by the user's keyboard input to:

However, during the direct ASCII /mail input interval, our OnEndEdit / ITfEditRecord diagnostic path produces no committed-text edit observation.

The text is visibly inserted into the control, but the edit is not observable through the same TSF path that works in Packaged Notepad.

Result 3: RichEdit

We repeated the same test using:

The result is the same as with the standard EDIT control:

• TSF service activation succeeds;
• context/sink attachment succeeds;
• focus remains on the RichEdit control;
• the final text is correctly:

but the direct ASCII insertion produces no committed-text edit observation through our current ITfTextEditSink / ITfEditRecord diagnostic path.

Questions

Is this host-dependent behavior expected by TSF design?

In particular, is a TSF text service guaranteed to receive ITfTextEditSink::OnEndEdit notifications for direct committed ASCII edits in standard Win32 EDIT and RichEdit controls when no TSF composition is active?

1. If such notifications are not guaranteed, what is the Microsoft-recommended supported architecture for observing direct keyboard text input such as /mail across Windows edit controls?
2. Is there a supported TSF architecture that allows this while the user continues to use Microsoft IME as the active input method, without requiring the user to manually switch to another input profile?

We specifically want to avoid unsupported or intrusive approaches such as keyboard hooks, clipboard monitoring, SendInput, or simulated deletion/retyping.

At this point, we are trying to determine whether the difference between Packaged Notepad and standard EDIT/RichEdit is:

• expected TSF behavior;
• a limitation of this observation approach; or
• an indication that our TSF integration for these controls is incomplete.

Any clarification on the expected TSF behavior, or guidance toward the appropriate supported architecture, would be greatly appreciated.

Thank you.