Add a Source Text Editor to Your HTML Editor

In a previous article, I described how to create an HTML editor using the MFC CHtmlEditCtrl class in a dialog box.  It could be used for creating "rich text" emails, chat-box composition, or perhaps even as an option for a syntax-highlighting code editor -- anywhere you would like to show HTML and let the user modify it.
After adding the source code editorAs the picture shows, we're going to add a source-text edit box so that you can make manual changes to the HTML source text -- giving you a way to explore some new options for this powerful control.

Use the Visual Studio Dialog Editor to add a multi-line Edit Control below the static text "placeholder" for the HTML editor.  Right-click it and Add a control-type variable to the parent dialog (m_ctHtmlSrcText).
  Add edit box with the Dialog EditorAdd this to the OnBnClickedLoadfile() function:
	m_ctHtmlSrcText.SetWindowTextW( m_sHtml ); // populate the Editbox

Open in new window

Now, wouldn't it be cool if we could update the source text box whenever the user made changes in the HTML editor?  Alas, there is no "OnChange" type notification from the control, so that's the next challenge: I needed to find a way to determine when the user has made a change in the HTML editor.  I looked at the GetIsDirty() function, but that flag gets set right after the first edit and there's no clean way to set it back after an update from the source text -- so I went with a different approach...

I decided to set up a window timer and use it to compare the most recently-copied HTML to the current HTML.  If it varies, then I re-populate the source text edit box, making sure to re-display it at the earlier scroll position.

And of course, we want to do a similar thing when the user modifies the HTML source text -- update the browser view with the changes.  Here's the code for all of that:

                      // update the HTML source box with changes from HTML Editor
                      void CEditHtmlDlg::SyncSrcToHtml()
                      	m_ctlEditHtml.GetDocumentHTML( m_sHtml );
                      	int nLine= m_ctHtmlSrcText.GetFirstVisibleLine(); // remember cur pos
                      	m_ctHtmlSrcText.LockWindowUpdate(); // avoid some flashing
                      	m_ctHtmlSrcText.SetWindowTextW( m_sHtml );
                      	m_ctHtmlSrcText.LineScroll(nLine, 0);
                      	m_fSrcNeedsSync= false; 
                      // update the Browser view changes from source text box
                      void CEditHtmlDlg::SyncHtmlToSrc()
                      	//------- all this to locate the scroll position...
                      	long nOffsetTop;
                      	IHTMLDocument2* pDoc;
                      	BOOL fRet= m_ctlEditHtml.GetDHtmlDocument( &pDoc );
                      	IHTMLElement* pBody;
                      	pDoc->get_body( &pBody );
                      	IHTMLElement2* pBody2;
                      	pBody->QueryInterface (IID_IHTMLElement2, (void**)&pBody2);
                      	pBody2->get_scrollTop( &nOffsetTop );
                      	//------- update the HTML
                      	m_ctHtmlSrcText.GetWindowTextW( m_sHtml );
                      	m_ctlEditHtml.SetDocumentHTML( m_sHtml );
                      	m_ctlEditHtml.LockWindowUpdate(); // avoid some flashing
                      	AwaitReady( 2 ); // CHtmlEditCtrl takes time for "document complete"
                      	//------- now scroll back to saved position
                      	IHTMLWindow2* pWin;
                      	pDoc->get_parentWindow( &pWin );
                      	m_fHtmlNeedsSync= false; 

Open in new window

Updating the source text window was basically a no-brainer, but handling the HTML editor update was a bit trickier.  Re-loading the HTML into the CHtmlEditCtrl causes it to redisplay at the top -- a very rude thing to do to a user.  I had to use the IHTMLElement2 get_scrollTop for the document body to obtain the current scroll position and the IHTMLWindow2 scrollTo function to restore it after reloading the HTML.

I found that without the call to AwaitReady (in line 32), the scrollTo function was ignored -- the embedded browser control needs a short time to reprocess the HTML.  So I used a technique from an earlier article to delay processing until the control indicates it is ready.  You'll find the AwaitReady() function in the project source code available for download at the end of this article.

In the Dialog Editor, right-click the source text edit control and use Add Event Handler... to create an OnEnChange handler to the dialog class.

Here's the OnTimer function and the CEdit's EN_CHANGE notification handler that use the SyncXxxxx functions:
void CEditHtmlDlg::OnEnChangeHtmlsrc()
                      	m_dwLastEnChangeTick= GetTickCount();		
                      	m_fHtmlNeedsSync= true;
                      // I used a StartTimer() in OnInit Dialog
                      // to execute this 10 times per second
                      void CEditHtmlDlg::OnTimer(UINT_PTR nIDEvent)
                      	if ( m_fSrcNeedsSync ) {
                      		SyncSrcToHtml();  // update source view, set m_fSrcNeedsSync false
                      	else { // check to see if HTML has changed
                      		CString sCurHtml;
                      		m_ctlEditHtml.GetDocumentHTML( sCurHtml );
                      		if ( sCurHtml != m_sHtml ) {
                      			m_sHtml= sCurHtml;
                      			m_fSrcNeedsSync= true; // update on next pass through
                      	if ( m_fHtmlNeedsSync ) {
                      		// here, we wait until the user stops typing (1 second)...
                      		if( GetTickCount() > m_dwLastEnChangeTick + M_MsDelayBeforeUpdate ) {
                      			SyncHtmlToSrc();  // update HTML view, set m_fHtmlNeedsSync false

Open in new window

Some notes on the above code:
I added:
         SetTimer( M_UpdateTimerID, 100, 0 );
to my OnInitDialog function, and used the Class Wizard to add the WM_TIMER handler.  Thus, the OnTimer function executes 10 times per second.

Line 18 looks like it might be a problem -- ten times per second, the code fetches the HTML source text form the CHtmlEditCtrl and compares it to the previously-saved text.  That seems like a lot of processing.  However, most HTML files are relatively short and CPUs are fast.  As a pragmatic test, even when I tried doing it 100 times per second on a large HTML file, I did not overburden my CPU.  If you want, you can decrease the timer to five times or twice per second.

Line 25 looks at a time-value variable that gets set each time OnEnChangeHtmlsrc gets triggered (e.g., when the user types or pastes or deletes in the source text window).  If less than one second has elapsed since the last such editing change, it does nothing.  The end result is that you can finish your typing without being interrupted.
We now have a dialog-based (non Doc/View) HTML editor that also displays and lets you modify the source HTML.  It automatically updates one when you modify the other.  We had to work around the lack of an "On Change" notification from CHtmlEditCtrl, but the timer-based solution works well.

In the next installment, we'll add some functionality to let the user set colors, create bullet lists, and so forth.

Project Source Code
The full source code for this project is available for download.  It includes a VS2008 project file.


CHtmlEditCtrl Class

CHtmlEditCtrlBase Class

MSHTML Editing Overviews and Tutorials

IHTMLElement2 Interface

IHTMLWindow2 Interface

=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=
If you liked this article and want to see more from this author,  please click the Yes button near the:
      Was this article helpful?
label that is just below and to the right of this text.   Thanks!
=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=-=- =-=-=-=

Comments (3)

aikimarkGet vaccinated; Social distance; Wear a mask
Top Expert 2014

What happens if the user's change results in not-valid HTML?
Author of the Year 2009


Its kind of interesting... The object takes action to correct the problem.  Let's say that you edit < DIV> to be <BIV>.   The "BIV" is ignored as an unknown tag and a new < DIV> is inserted directly in front of the closing < / DIV>.

In playing around with copy-to-clipboard operations, I read that Microsoft states that it always places a "valid HTML fragment" on the clipboard.   My guess is that they have some interesting technology in place to create valid HTML from invalid HTML.

There is no standard for how a browser should "correct" invalid HTML.  I recall a long argument in the Browsers TA about this.  Some say that "standards based browsers" are more correct when they just break (and show garbage) than Microsoft's technique of attempting to find a reasonable way to render the bad HTML.
aikimarkGet vaccinated; Social distance; Wear a mask
Top Expert 2014

Maybe that is how some of the newer browsers get better performance results.  They sacrifice some error-checking and other compensation.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.