Introduction

Now that the excitement of having something actually work has worn off we can take a critical look at what we have done.

What have we done? We have shown that:

we can 'create' an editor that lets us format text with text attributes such as bold face, italic, etc.
we can execute the text and put the result back in the text.

Sounds good but the list of things we haven't done and haven't considered is much longer. Here are some of the obvious entries:

What about text that is not part of a formula,
Where should the results go? Surely not at the bottom of the page.
Didn't we mention charts in our wish list?
There is a lot more to formatting than bold,italic and underline.
What is supposed to happen when the user writes something that the program doesn't understand?

In order to make some visible progress it is often a good idea to tackle the easy problems first, at least if they are problems that must be solved and not just vague wishes. The problem is of course that we don't know which problems are easiest to solve without examining them. Sometimes examining the problem just turns up more problems, sometimes it will turn out to not really be a problem at all.

Lets take our not done items in turn.

Text that is not part of a formula

Our prototype works by passing the whole text of the document to the Script object. This means that the whole text must be legal in the language of the script engine. Our formulas are just statements in that language. Programs are composed of three types of things:

statements
comments
whitespace

So the text that is not part of a formula is by definition either whitespace or comments. If it contains any printable characters then it can't be whitespace so it must be comments. So, we can include any text we like so long as it can be contained in comments because the scripting engine will just treat it as whitespace and ignore it.

There are several different syntaxes for comments, sometimes one language will allow more than one type. When using the language purely for programming it usually doesn't matter very much how comments are delineated but in our case the comments will be a very important part of the text so it is important that the syntax doesn't get in the way. We have already decided to limit ourselves to either VBScript or JScript so all we have to do is decide which has the better syntax for comments, while bearing in mind that we might want to change our mind later for other reasons.

The syntax for comments in VBScript is very simple, it is the same as Visual Basic. A comment is introduced by a single ASCII quotation mark:

 ' this is a comment

or the word REM (case doesn't matter):

 rem this line
 ReM and this line are both comments

JScript is a little different:

 // this is a single line comment

 /* this is also a single line comment */

but:

 /* This
    is
    a 
    multiline
    comment */

For our purposes I think it is obvious that the JScript syntax is more convenient for writing paragraphs of text. If we use JScript then we can simply write our text and formulas quite naturally except for remembering to enclose the blocks of text in /*..*/. Best of all we don't have to do any extra programming to make this work.

Exercises

Run the program and add comments using the two different comment styles. Run the document to convince yourself that the comments do not affect the result.

Where should the output go?

So far the output has simply been appended to the end of the document. This is obviously not very useful. We probably want to be able to put the answers near the questions, values near the formulas that determine them.

Also we don't want repeated evaluations to add new copies of the values to the end of the document. One way around this is to place some special sequence of characters in the text that will be replaced by the answers. For instance we could write a document that looks something like this:

 Ttop=55 // deg C
 Tbot=Ttop-6
 
 /*
 The bottom temperature is <Tbot>. Which is six degrees below the top.
 */

The first line sets variable Ttop to 55, the next calculates the value of Tbot. Then we have a multiline comment that has embedded in it the character sequence <Tbot>; this is called a macro.

Now we can execute the program which will set the values of the variables and then we can scan the program text looking for macros. When we find a macro we can ask the Script object for the value of the variable it names and replace the macro with the value.

It is easy to find the macros, just a few InStr calls will do it or we can get more sophisticated and use regular expressions. After evaluation and macro substitution the document would look like this:

 Ttop=55 // deg C
 Tbot=Ttop-6
 
 /*
 The bottom temperature is 49. Which is six degrees below the top.
 */

Unfortunately there is a serious flaw in this scheme: it only works the first time we evaluate the document. This is because we have replaced the macro with the value just as though we were running a normal macro-processor; see, for example, m4 Macro Processor Overview. If we modify the document to change the constant 6 to 9 and re-evaluate the document the result will not change.

In our case the input document is also the output document so we have to insert the output in such a way that it can be re-evaluated and have the results updated.

One solution is to modify the method by which we show the result so that the macro is not replaced but is instead modified. Then the document might look like this after evaluation:

 Ttop=55 // deg C
 Tbot=Ttop-6
 
 /*
 The bottom temperature is <Tbot=49>. Which is six degrees below the top.
 */

Now we just have to make some simple modifications to the code, as yet unwritten, that scans the text for the macros and to the code that inserts the result. All that is required is that we recognize the macro and split it into two parts: name and value. The name and the characters that are used to indicate that this is a macro are left unchanged while the value is replaced. When you write the document you would write the macro like this:

 <Tbot=>

That is, the value is empty and will be filled in when the value is known.

Exercises

Try to think of a general procedure for replacing the placeholders with the values of the variables.
What will happen if the same variable has different values in different parts of the document? What should happen?

Charts and other objects

Understanding that there are different ways of viewing the same thing and that different things can be viewed in the same way is one of the most important lessons to be learnt in computer programming.

If we regard charts as simply another kind of value all questions regarding the generation and inclusion of charts become questions about what kind of function has to be written to generate the value and how to automatically insert that value in the document. Once the problem is phrased in this way it becomes obvious that we can use the same macro technique to display a chart that we use to display a number. now all we have to do is create a function that creates a chart.

Of course there are lots of details to be dealt with yet. Still if we simply assume that there is a function somewhere that creates charts, perhaps as bitmap images, all we have to do is find a way of calling it.

Formatting

In principle we can use any formatting that is supported by the Rich Text Box control. we should be able to provide hot keys, menus and toolbar buttons to set the type face, type size, indentation, justification and so on.

Syntax errors, typing mistakes, etc

To do.

Exercises

Create a new project with a Rich text Box control. Experiment with the properties and methods of the control to set type faces, sizes, indentation, etc. Create a button for each feature.
Extend the application to let the user pick the type face, etc., by showing the font selection dialog box.

Previous: JArithmetic

Contents

Next: Jarithmetic Round Two Implementation