HtmlEditor : Phorum 5
This is the discussion forum for the HtmlEditor. See also the HtmlEditor home page, where you can download the control, and the Documentation Wiki, a collaborative project for documenting the control.
A few tips
Posted by: Tim Anderson (---.server.ntl.com)
Date: Friday, 15-Nov-2002, 09:14:15
I've slightly improved the demo app to give a few more ideas about how to use the control.
If you're just displaying HTML, then you've not got much to think about. If you want to use the control as an editor, there's a bit more work to do. The control has a few properties and events that will help.
- First, note that the control supports Ctrl-C, Ctrl-X, Ctrl-Z, Ctrl-A with the standard results.
- A few useful events are:
UpdateUI, which lets you update things like bold/italic indicators or style dropdowns with the current state at the caret position.
ReadyStateChanged, informs you that the state of the control has changed. It needs to be "complete" before you can do much with it. However, the control aims to protect you from trying to do stuff when the ReadyState is wrong, to some extent.
HTMLKeypress, fires in Design (edit) mode when keys are typed in the control. The EventArgs gives you a reference to the HTMLEventObject from which you can get information about the key and its context.
- The cotnrol's currentElement property gives you a ref. to the IHTMLElement at the caret position. Of course this might not be a block element, it could be anything. You can navigate through the DOM to get to the element you need to work on.
Much of the time you work with the Document property which is a reference to the HTMLDocument object. You can fire off commands with the document's execCommand method (used in the demo app for cut, copy, paste) and of course access and edit the DOM. This is pretty much the same as working with the DOM in script. Extensive documentation in MSDN.
The control's Print method lets you specify print preview and also use print templates.
If you poke through the code, you'll see that there are many more events that could be exposed. After all, MSHTML is probably the largest and most complex COM component in Windows. However there is a problem with handling document events - either a bug in the control, or in the Framework. I've worked around this problem by not hooking up directly to the HTMLDocumentEvents2 interface, but catching the most important events in other ways. Perhaps it will start working as it should in the next release of the Framework.
Tim
If you're just displaying HTML, then you've not got much to think about. If you want to use the control as an editor, there's a bit more work to do. The control has a few properties and events that will help.
- First, note that the control supports Ctrl-C, Ctrl-X, Ctrl-Z, Ctrl-A with the standard results.
- A few useful events are:
UpdateUI, which lets you update things like bold/italic indicators or style dropdowns with the current state at the caret position.
ReadyStateChanged, informs you that the state of the control has changed. It needs to be "complete" before you can do much with it. However, the control aims to protect you from trying to do stuff when the ReadyState is wrong, to some extent.
HTMLKeypress, fires in Design (edit) mode when keys are typed in the control. The EventArgs gives you a reference to the HTMLEventObject from which you can get information about the key and its context.
- The cotnrol's currentElement property gives you a ref. to the IHTMLElement at the caret position. Of course this might not be a block element, it could be anything. You can navigate through the DOM to get to the element you need to work on.
Much of the time you work with the Document property which is a reference to the HTMLDocument object. You can fire off commands with the document's execCommand method (used in the demo app for cut, copy, paste) and of course access and edit the DOM. This is pretty much the same as working with the DOM in script. Extensive documentation in MSDN.
The control's Print method lets you specify print preview and also use print templates.
If you poke through the code, you'll see that there are many more events that could be exposed. After all, MSHTML is probably the largest and most complex COM component in Windows. However there is a problem with handling document events - either a bug in the control, or in the Framework. I've worked around this problem by not hooking up directly to the HTMLDocumentEvents2 interface, but catching the most important events in other ways. Perhaps it will start working as it should in the next release of the Framework.
Tim
Re: A few tips
Posted by: Tim Anderson (---.server.ntl.com)
Date: Monday, 18-Nov-2002, 08:03:45
Just to add that HTMLKeyPress only fired for Ctrl combinations in the first upload. I've now changed it to fire for all keypresses. However, it only fires in Design (Edit) mode.
Tim
Tim