Wednesday, December 25, 2002 - Wed, 25 Dec 2002

Back to the new version of Richview and getting the checkpoint names to work in exported html and rtf. A new option to UseCheckpointName was added to Richview and I can use that instead of my custom code. Setting that up, it seems to almost work. All the hyperlinks work fine to create an html document. But there’s problems with them in rtf. Load the rtf file into Microsoft Word and the links are not created correctly. After some experimentation, I found the Richview code and there looks like an error in that hyphens in hyperlinks are converted to underscores, but they are not converted for the bookmarks. Also, a leading ‘#’ in a hyperlink is converted to an underscore but it shouldn’t be. After taking an hour to find the error, its easy to patch the code for now and I’ll report the problem to Sergey.

While doing that experimentation, I see that the Save Dialog I use for my Export menu doesn’t have its default paths and extensions set up well. I should fix them and make them consistent with my Load and Save menu dialogs. How exactly they should be set up - I don’t know. Should I maintain one directory each for Loading, Saving and Exporting, or should I have one directory maintained and used for all three? I’ll have to look at other programs and see how they do it and then think about it.

So going through the dialogs, I see it isn’t as bad as I thought. I use one default open/save directory which I store in the Registry. Then the Open directory can change independently from the directory in the save/export dialogs during one execution of Behold. What wasn’t working was the extensions. When I went from saving a Behold file to exporting an rtf file, the default file name still had the .bho extension rather than .rtf, and I’ve now fixed that.

The key thing at this point with Behold is whenever I work with it and find little things wrong, I should fix them before going back to what I was working on before.

Now the problem with the new Print Preview being so slow: Time to take my Profiler out - that’s a program that checks how long your program takes to execute each routine - and try to analyze and see what’s going on. This is not for the faint-hearted, since the Profiler does modify source code heavily to put monitoring code around each routine. If something went wrong, you could lose your source. So a full backup is required before I start.

Using the profiler, it quickly became obvious where the problem was. It was in the formatting of the lines of the Print Preview document. There is a Windows call, GetTextExtentExPoint, that determines the number of characters that will fit on a line. It happens that this function takes just a few milliseconds too long on each call, and thousands of calls are made, one for each paragraph. It is more efficient to call a another Windows function, GetTextExtentPoint32, which is much faster that finds the length of a number of characters. Then using a Newtonian search, converge on the number of characters that fit in the line length. Even 5 calls to this other function is many times faster that the first, so a very large speedup is possible. I analyzed this back in May 2000 for Sergey when the formatting of the document seemed to take too long, and he then improved that code. This time, the same thing has slipped into the Print Preview. I’ll let Sergey know about this and hopefully he will improve the Print Preview code.