Sorry for not having been on the UT in the last couple of months.I read you reply just now.

My own Clickwork shareware app has an rtf help system that I built back then myself. So, I'm 'experienced' now in creating an rtf editor and an html editor. Creating both were good learning experiences.

Indeed, the version I made available to all (https://github.com/pvalenca1/RTE) is not, by itself, good enough for any commercial package, but in my case it was successfully implemented in a (starter) app that runs in a very controlled environment. We know exactly which versions of Windows, Internet Explorer, OCXs and DLLs are available. We don't expect the (approx 500) users to do 'weird' things in edit mode, like inserting a hyperlink to youtube, although that's possible. And if they do, and thus perhaps cause an error or a catch-22 (e.g. how to return from that youtube page), we can always tell them not to do 'that' anymore, or press the Edit button and then press Cancel, or block such usage. (Offering the famous back-button is something that I will gonna try to implement anyway. Advice is appreciated.)

The big advantage is that these users are now able to make lists, use color, sizes, fonts, pictures and even insert hyperlinks. And this is something that native vfp never had and never will gonna get.




>Yup...
>
>Frankly I don't feel like wasting my time on looking at WYSIWYG editors any more as a solution to any problem, because they are almost always slow and clunky and unintuitive. For simple scenarios - sure they work, but then why bother for simple scenarios in the first place - if all you need is simple things like bold, italics, lists etc. there are much easier and more reliable text based solutions that are more consistent and reliable.
>
>Even reasonably good implementations like the one that Medium uses (which I would consider the state of the art of these types of editors) has tons of odd quirks and strange behaviors (mostly related around line breaks) and when you add in the integration within an application where you mismatch the HTML UI with the host form API for things like context menus common editor tasks (drag and drop? Copy Paste of rich content) the behavior either doesn't work at all or works differently than you would expect.
>
>I'm not disparaging your work, my beef here is with the idea of using an HTML editor for any type of application - even inside of Web applications. It's generally not a good solution to a text editing problem especially not in FoxPro where you will be fighting the ActiveX integration issues with focus stealing and activation failures on top of everything else.
>
>I'm not bringing this up without context. I've built an HTML editor in Help Builder years ago and spent countless hours trying to get it to work well. It's a huge job to build a truly useful HTML editor as you need a ton of support tooling. Hotkeys, support menus, the ability to embed content etc.The HTML editor code made up nearly a 1/4 of the entire Help Builder code base at some point. It worked pretty well, but not well enough to be a marketable solution for a text editor for a commercial product. It was just too weird in terms of behavior for editing the large text content required to create documentation. Not saying that my implementation was the best or as good as it could have been done (especially in those days prior to IE 10+'s HTML and proper DOM support), but in subsequent years more than 80% of support requests were related to that editor and mostly to issues that had no resolution. Usage indicated that hardly anyone used the HTML editor compared to the plain text editor which used a pseudo-markup text format that long predated things like Markdown (which is what I use now) which in effect means all that effort that went into that editor was basically a waste of time. I know I never used that editor because it was just so much faster to create the plain text content (aided by toolbar and hot key shortcuts).
>
>Some of the things I found with the HTML editor were:
>
>* Hard C5 crashes of the application (ActiveX issues)
>* Focus issues - ActiveX steals focus requiring multi-activation of other controls (especially a problem if you use other ActiveX controls)
>* Form Focus - bringing up other dialogs from within editor focused content will not activate in proper z-order
>* Editing issues - mostly around
>
>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.
>
>+++ Rick ---
>
>
>>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.