Summary

View.Text should expose a CWP-compliant text-change workflow at the base View level.

View.TextChanged already exists, but it is currently a plain EventHandler notification. The missing piece is a matching pre-change TextChanging event, and the existing post-change notification should be made part of the Cancellable Work Pattern (CWP).

Proposal

Add a signal-only, cancellable pre-change event to View:

public event EventHandler<CancelEventArgs>? TextChanging;

Keep TextChanged signal-only as well. It should not carry old text, new text, replacement text, offsets, or edit details.

The base View.Text setter should follow the usual CWP flow:

1. If the new value equals the current value, return without raising either event.
2. Raise/call the TextChanging CWP hook before mutating text.
3. If the change is canceled, leave Text unchanged and do not raise TextChanged.
4. Apply the text change.
5. Raise/call TextChanged after the change.

Why signal-only

At the View level, Text is not always an editable text buffer. Depending on the derived view, it may represent a label, caption, title, formatted content, document projection, or other display text. A base event that carries old/new text would imply more precise text-edit semantics than View can guarantee for all subclasses.

Derived controls that need richer text-edit semantics can continue to expose their own more specific events. For example, text-entry controls may expose cancellable or editable args with proposed replacement text, while View remains a broad signal-only contract.

Impact on derived views

This gives controls such as Editor : View a natural inherited event surface for text changes. One nuance: controls that override Text and do not call base.Text still need to participate in the workflow explicitly. For example, Editor maps Text to its document rather than to View's backing text, so it would inherit the event API but must raise the CWP hooks from its override or model-change path.

Acceptance criteria

• View exposes TextChanging as a signal-only CWP pre-change event.
• View.TextChanged remains signal-only and does not carry old/new text.
• View.Text raises TextChanging before changing text and TextChanged after changing text.
• Canceling TextChanging prevents the text mutation and suppresses TextChanged.
• Setting View.Text to the existing value remains a no-op and raises neither event.
• XML docs clarify that these are broad View-level text-change signals, not detailed text-edit events.