Problem
When implementing mouse-wheel scrolling on a child view that should forward to a parent (e.g., a gutter subview inside an Editor's Padding that needs to scroll the Editor), the correct pattern is:
- Child adds only
MouseBindings (e.g., MouseBindings.Add(MouseFlags.WheeledUp, Command.ScrollUp)) — no AddCommand handler.
- Parent sets
CommandsToBubbleUp = [Command.ScrollUp, Command.ScrollDown, ...]
- When the child receives the wheel event, the mouse binding fires the command,
DefaultCommandNotBoundHandler runs → TryBubbleUp finds the ancestor with the command in CommandsToBubbleUp → invokes it.
This is elegant and idiomatic, but extremely hard to discover:
command-diagrams.md focuses on Accept/Activate flows and doesn't mention scroll or mouse-wheel forwarding.
- The
CommandNotBound event XML docs describe the mechanism but don't explain when to use it (i.e., "add a MouseBinding without a handler to let it bubble").
CommandsToBubbleUp docs don't mention the AdornmentView special case (adornment.Adornment?.Parent) which is critical for views hosted in Padding/Border.
- There's no example showing the "child forwards wheel to parent" pattern which is a very common need.
Suggested Improvements
-
Add a "Mouse Event Forwarding" section to command-diagrams.md (or a new mouse-commands.md) showing:
- The pattern: MouseBinding without AddCommand → CommandNotBound → TryBubbleUp → parent handles
- A concrete example (e.g., ScrollBar/Gutter wheel forwarding)
- The AdornmentView special case in
CommandWillBubbleToAncestor
-
Improve CommandsToBubbleUp API docs to:
- Explicitly mention that views in Padding/Border/Margin bubble to the Adornment's Parent (not SuperView)
- Show a code snippet of the wheel-forwarding pattern
-
Improve CommandNotBound event docs to:
- Clarify that adding a MouseBinding without an AddCommand handler is intentional and idiomatic
- Link to the bubbling docs
-
Add a scenario/example in UICatalog demonstrating mouse-wheel forwarding between views.
Context
Discovered while implementing gutter mousewheel scrolling for the Editor library (gui-cs/Editor#96). The pattern works perfectly once found, but required reading View.Command.cs source and CommandBridge.cs to piece together.
Problem
When implementing mouse-wheel scrolling on a child view that should forward to a parent (e.g., a gutter subview inside an Editor's Padding that needs to scroll the Editor), the correct pattern is:
MouseBindings(e.g.,MouseBindings.Add(MouseFlags.WheeledUp, Command.ScrollUp)) — noAddCommandhandler.CommandsToBubbleUp = [Command.ScrollUp, Command.ScrollDown, ...]DefaultCommandNotBoundHandlerruns →TryBubbleUpfinds the ancestor with the command inCommandsToBubbleUp→ invokes it.This is elegant and idiomatic, but extremely hard to discover:
command-diagrams.mdfocuses on Accept/Activate flows and doesn't mention scroll or mouse-wheel forwarding.CommandNotBoundevent XML docs describe the mechanism but don't explain when to use it (i.e., "add a MouseBinding without a handler to let it bubble").CommandsToBubbleUpdocs don't mention the AdornmentView special case (adornment.Adornment?.Parent) which is critical for views hosted in Padding/Border.Suggested Improvements
Add a "Mouse Event Forwarding" section to
command-diagrams.md(or a newmouse-commands.md) showing:CommandWillBubbleToAncestorImprove
CommandsToBubbleUpAPI docs to:Improve
CommandNotBoundevent docs to:Add a scenario/example in UICatalog demonstrating mouse-wheel forwarding between views.
Context
Discovered while implementing gutter mousewheel scrolling for the Editor library (gui-cs/Editor#96). The pattern works perfectly once found, but required reading
View.Command.cssource andCommandBridge.csto piece together.