The HTML Editing support in Help Builder will be the end of me <g>. The issues just never seem to end. Just when I get one or the other licked another pops up. Aaaargh.

I’m pretty happy with where the HTML Editing support in Help Builder has gone at this point. It’s quite workable and even a text based bigot like myself will find himself more and more frequently using visual editing for topics that have a lot of visual aspects (mostly tables and images and special indentations etc.) elements.

However, I have one issue that I have been struggling with for a LONG time and cannot resolve, and maybe somebody has some insight into this. The problem has to do with focus of the edit control.

I’m using the standard Web Browser control and I use

Browser.Document.Body.ContentEditable = "true"

to get the document into designmode. There are a bunch of event hookups that deal with menu and key and click trapping. Everything works well inside of the application itself and focusing properly works. I can move to other controls and back, even other windows and back and when I come back to the Web browser in Edit mode focus properly returns.

However, when I click or ALT-Tab on another application while focus is on the Web Browser and then return back to Help Builder, the Edit control looses its edit focus: The cursor is invisible and any text typed is not going anywhere.

It turns out that the browser IS in fact getting focus back – I’m trapping keystroke events on the document and I can see those events firing, but the control doesn’t activate in edit mode until I physically click the mouse in the client area.

From a usability POV this suck big time as it forces you to pick up the mouse in order to find your spot again. I do this fairly frequently when documenting where you flip back and forth between the application your documenting and the text I’m editing.

So, problem #1 is that the Edit focus doesn’t properly return to the control automatically. What’s worse though is that I haven’t even been able to programmatically reset the focus either. I’ve tried a ton of things in this respect:

• Setting a selection and selecting it (I can see it but it’s not ‘active’)
• Focusing the form, the control the document the active area
• resetting DesignMode and ContentEditable flags
• Sending WM_ACTIVATE messages, WM_KILLFOCUS messages etc.

None of this has worked. I cannot figure out how to get the control back into edit focus.

My last resort has been to using WinAPI SendMessage calls to try to send messages to the various controls that make up the Web browser control (there are 3: The ActiveX container, the document and IE Host container) and sending various messages to it. However, I’ve only been guessing at which messages to send and in which order. Even looking at the SPY++ message trapping yielded little reproducible message sequences that I could use.

Does anybody have any idea how to get the Web Browser control back into Edit mode with a cursor ready and for entry programmatically?

I've been trying to solve this problem for a few weeks now off and on and I'm getting a bit desperate...

Any help would be appreciated.