>If you want to build a complete editor you almost certainly have to implement the IHtmlElementEvents interface to capture various key and mouse events. Most likley for copy, paste, and context menu operations and potentially click and right click handlers if you need custom actions.
>
>Honestly I'm quite surprised so many people try to still do this themselves. I've been down this path a few times specifically with Help Builder which had a sophisticated hand rolled HTML editor. It works for simple stuff, but editing is dreadfully slow, and there are just a boat load of quirks with HTML editing UI even if you use a decent browser like Chrome let alone the IE WebBrowser control running in FoxPro. And even when you do there are many things that really suck in HTML editing (line breaks in particular) and the output that the editor generates. There's no support for spell checking either. It's incredibly difficult to build a natural feeling editor for any non-trivial input - and if you just want a few simple things like bold/italic/lists/headers then something like Markdown is a much better way to expose that.

This is just an expression builder, so I'd need perhaps just four colors to paint the syntax. No heavy artillery. The essential part, though, is offering an intellisense-like dropdown every now and then, depending on the context.

>If you really need a WYSIWYG HTML editor I'd recommend looking into automating one of the many JavaScript HTML editor controls that are available that have solved this problem most likely in a much richer fashion than you'll be able to do with FoxPro automation. It's easier to do the FoxPro -> JavaScript interaction for pulling just the results out and most of those editors usally have a real API you can use to push data and selections into the editor in a much easier and much more efficient way than using the DOM from FoxPro.

I was thinking of that at times, but it seems a bit of an overkill for just a couple of features that I need.

>Or even better - forget about quirky WYSIWYG HTML editing completely and use simple text based markup with Markdown or AsciiDoc along with an as you type preview. This is the route I eventually took in Help Builder and it's a much better solution than the unreliable HTML editing and focus issues associated with HTML editing. I still use HTML and JavaScript interop (ACE Editor for the Markdown editing) but it's much more predictable than the logic required to handle all the crazy HTML events that are often needed to handle simple things.

I'm vastly disappointed with the event handler (as mentioned in the other branch of the thread). Doesn't get any parameters! What was it supposed to handle, then?

I'm thinking of putting that editbox back and displaying the html on the side, as a preview, like you say. That I can do in my sleep.