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
}

Private Sub CommentForm_Load(sender As Object, e As EventArgs)
    htmlEditor1.Toolbar1.Visible = False
    htmlEditor1.Toolbar2.Visible = False
    htmlEditor1.ToolbarFooter.Visible = False ' hides the WYSIWYG / Source / Preview tabs too
End Sub

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);
}

Private Sub CommentForm_Load(sender As Object, e As EventArgs)
    htmlEditor1.Toolbar1.Visible = False
    htmlEditor1.Toolbar2.Visible = False
    htmlEditor1.ToolbarFooter.Visible = False
    Dim items = htmlEditor1.ToolbarItemOverrider.ToolbarItems
    customToolStrip.Items.Add(items.Bold)
    customToolStrip.Items.Add(items.Italic)
    customToolStrip.Items.Add(items.Underline)
End Sub

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.