Rendering the Text More Effectively

The current XML Notepad is pretty rudimentary, and if it s used incorrectly, bad things could happen. If the user cursors into a tag and edits it incorrectly, the text might no longer be valid XML and we might never know it. I thought about a number of ways of making this better.

Use RichTextBox Instead of TextBox

If we used the RichTextBox instead of TextBox, we could do some great things. For example, we could color all the tags a different color from the text so that the user would more readily see where not to type. We could even render the different tag contents in a different font: we could make the section titles large and bold, and the code lines could be in a fixed face, while the regular text was not.

Petzold had some useful information that might help with this. He addressed how to figure out what character was selected when using a variable-width font, and he showed how to know what is and is not scrolled on the screen so that we could render the screen more quickly by rendering only the text that s actually displayed. That would be much more efficient than what we are doing now.

Petzold even showed enough so that we could render not to a RichTextBox but to a pane of our own invention without much difficulty. He even showed how to write some unsafe code that accesses the Win32 operations on the caret (that little vertical bar that shows up between the characters you are typing when editing). Using these ideas, we could make a much better experience for the customer.

Keeping the XML Correct

I thought a lot about the user possibly messing up the XML. He might type inside a tag, changing a <P> to a <p> or worse , to <H2>, without changing the corresponding other end. He could get the tags unbalanced, and the file would no longer contain legitimate XML, which of course would be bad.

I thought about displaying the XML not in a TextBox but in some kind of tree browser, showing the shape of the XML in the tree and the details of each paragraph in a separate window. It might be sort of like the Explorer, with the directory tree on the left and the text on the right. The problem with this idea is that on the text side, we want to see all levels in the file, not just one selected one.

I thought about having two columns , one showing the tags and another showing the text. This might make keeping things lined up difficult, because one line on the tag side might consume many lines on the text side, due to word-wrap. I thought about that for a while and couldn t really see any way to make the tags and text line up. I d like to experiment a little to be sure.

Protect the Tags

It might be possible to catch all the cursor changes. The main way the user could mess up a tag would be to cursor into one and edit it. We could change the program to detect all cursor movements (not forgetting the mouse) and keep him from going inside a tag. This might be a problem if the user actually needed to go in there, but it would be safe. We could maybe add a story to insert a tag that the program doesn t know ”that feature would certainly be useful someday. Or perhaps the story should be to add a special command for editing a tag on purpose, which prevents the user from doing it by accident .

Verify the Structure

It might be possible to verify the structure all the time, every time the user does anything. Suppose that on every event we parsed the XML. A simple loop would be sufficient:

 read the file 
 if theres an opening tag, push it on a stack 
 if theres a closing tag, pop the stack and compare 
 if they match, the syntax is OK, otherwise not. 

That would be cool to write, not difficult, and it would do a good job, though not a perfect one, of ensuring that nothing is broken in the structure. There could be a red light/green light somewhere in the display, and the light would go red, and probably beep, whenever the structure was broken.

One problem would be a less than sign (<) in the text, but that s already a problem. We haven t had a story for it, but less than in the text needs to be changed to &lt; anyway. We know they re going to ask for that sooner or later, so maybe we should just build it in now.

TextModel as a Tree

An even better solution would be to have the TextModel be a tree of tags, rather than just a bunch of strings. That way, a sect1 tag would have a title tag and a bunch of P tags as children. It would be easy to render the tree back to text. A simple pre-order scan of the tree should do it: it would be elementary tree processing.

One issue would arise in reading the text back into the model. But something like the push-down processing described earlier should do it. And we could probably create the tree for the new text, compare it to the old tree, and make sure that nothing too weird had happened .

It might also be possible to check the situation on essentially every keystroke. A quick check of the line that the cursor is on to see if nothing has changed might be sufficient to allow some kind of incremental updating of the TextModel s tree.