Replace the built-in toolbars with your own

Linh works on a desktop code-review tool used by a few thousand back-end engineers. The product has a comment thread next to every diff - inline reviews, pull-request approvals, the usual. For the past two years comments have been a plain TextBox, but Linh's design partner has been pushing for "just enough" formatting: bold for emphasis on a specific token name, italics for the occasional aside, underline almost never. No images, no tables, no fonts, no headings. The reviewers want to leave a comment, not author a blog post.

Linh evaluates WinFormHtmlEditor, likes the editing surface, and immediately hits a problem: the default control ships with two rows of toolbar buttons - thirty-something icons in total. Dropped into a 200-pixel-wide comment box, that toolbar dominates the UI and makes the actual comment area feel like an afterthought. She needs a stripped-down replacement.

Hiding the factory toolbars

The first move is simple. Toolbar1, Toolbar2, and ToolbarFooter are exposed as plain ToolStrip references on the editor. Linh hides all three in Form_Load:

private void CommentForm_Load(object sender, EventArgs e)

{

    htmlEditor1.Toolbar1.Visible      = false;

    htmlEditor1.Toolbar2.Visible      = false;

    htmlEditor1.ToolbarFooter.Visible = false;   // hides the WYSIWYG / Source / Preview tabs too

}

The editor is now a clean rectangle. No toolbar.

The three buttons Linh actually wants

She drops a custom ToolStrip above the editor on her comment form. Now she needs Bold, Italic, and Underline buttons in it - but she does not want to re-implement the click logic, re-find the icons, or write her own undo handling. Reading the source, she discovers ToolbarItemOverrider.ToolbarItems: a strongly-typed accessor that hands back the live ToolStripButton instances the editor already configured. Same icons, same tooltips (already localized through WinFormHtmlEditor.Language), same click logic, same checked-state toggling.

private void CommentForm_Load(object sender, EventArgs e)

{

    htmlEditor1.Toolbar1.Visible = false;

    htmlEditor1.Toolbar2.Visible = false;

    htmlEditor1.ToolbarFooter.Visible = false;



    var items = htmlEditor1.ToolbarItemOverrider.ToolbarItems;



    customToolStrip.Items.Add(items.Bold);

    customToolStrip.Items.Add(items.Italic);

    customToolStrip.Items.Add(items.Underline);

}

What Linh gets for free

Because she rehosted the editor's own button instances rather than building new ones from scratch, three behaviors keep working without any extra code:

• The editor's undo/redo stack, dirty tracking, and selection state stay correct - the user is still going through the editor's real commands.
• Tooltip localization driven by WinFormHtmlEditor.Language keeps working. When a reviewer switches the app to French, the tooltips switch with them.
• Pressed/checked state still works. When the caret sits inside bold text, the Bold button shows pressed - the editor toggles Checked on the underlying ToolStripButton regardless of which ToolStrip happens to host it.

The follow-up request

Two weeks in, the design partner asks Linh to also expose the Hyperlink button - reviewers want to link to other PRs. She adds one more line: customToolStrip.Items.Add(items.Hyperlink);. The Hyperlink dialog still pops up, the spell-check service still cleans up around the inserted anchor, the undo stack still records the change. She closes the ticket the same afternoon.

If a future scenario calls for a UI that is not a ToolStrip at all - a menu, a ribbon, a side-rail of buttons - the matching pattern is in Drive the editor from your own UI.