>FWIW I'm now using an HTML based Markdown editor so some of the issues (like focus) remain an issue, but because the vast majority of the code actually runs inside of the browser control itself it works a lot smoother. By comparison the editor text entry speed is also much better (in fact better than native FoxPro text input). In general I think this is a much better and much more reliable solution although that's also pretty code heavy to do right and still has to deal with some of hte very same ActiveX integration issues but on a much smaller scale.

Actually, if I had to have anything that would allow end users to edit HTML within the app, I'd also go for some in-browser tools. I'm regularly using a few of them (couple of forums, blog, and at work just switched from one wiki to another) and it generally works fine as long as you stay away from doing too many complicated things. Dropping images into text seems to work fine (except in most of the places in Confluence, where it insists on inserting a thumbnail and the link is just a plain text markup that you edit, not a real link that you can edit in a dialog, like you can in WordPress), typing after a link at the end of text may keep the insertion point inside the link (several editors still do that, including Thunderbird's, which has this problem for decades) and you have to insert a line break, type something after it and then go back and join paragraphs. Other than that, most of the stuff work just fine, with occasional fun when trying to join paragraphs in text which was imported from another platform.

Now that you mention a help builder, ouch. I can't even imagine what you had to go through to get those two or three kinds of footnotes or whatever special tags may be required for different entries (ISTR one was for internal links, which may be simple links in HTML, they were a real PITA in .rtf, 20 years ago when I did that, then those for index, and I guess main titles are just H1, H2.

There's one make it or break it test for any html editor, in-app or in-browser: can it handle rich text imported from Word as if it was written in itself. And it doesn't seem to matter whether it was copy-paste of a few paragraphs from Word, or a .doc(x) file saved as .html, or .html edited in word from scratch - they are all so whacky, and misbehave in any editor in many many ways. It's a house of cards which never falls right.

On another note, the issue I was trying to solve a couple of weeks ago, about the event handler not getting any parameters to handle, is now a non-issue. We simply gave up and went for doing the same with RTF text control. Which also has its own quirks, but is far simpler and its events fire at the right times.