Hmm Rick, you seem to have made up your mind about a richtexteditor based on shell.explorer.2 long time ago. Pity. I really had some hope (because you was one of the few who replied to my request for some help) that you'd make some time to spend some words to my attempt to build such an editor.
Instead of detailed suggestions on how to improve, you now - all of a sudden - make a statement that each attempt to build such an editor is a waste of energy and can also merely lead to a quirky tool.

For all those who now think negatively about such a richtexteditor based on shell.exploror.2: Please, at least try my attempt. Message ID: 1661201

Regards, Peter

>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.
>
>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.
>
>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.
>
>+++ Rick ---
>
>>I have a web browser object, set to editable, in a form. Now I want to use that object as a text entry (with, in the end, syntax coloring) and I've found Yousfi's article most helpful.
>>
>>But, but... the code in the implementation has no parameters! It reacts to _onkeydown() but I don't know which key, because there's nothing holding the value. I see he tried to resolve that by using GetAsyncKeyState API call, but he has to call it 255 times to find which key was last pressed - and not to mention anything about ctrl or alt... so is there a better interface to implement? Or a way to get to the event object from DOM - it's surely passed to the event inside the document, but not to the interface.