Saturday, May 28, 2005 - Sat, 28 May 2005

Thoughout all this, I was learning how the AnsiCompareStr sorted its character values. I figured maybe its best for me to write my own routine instead. It wouldn’t be that hard. After a few hours I had a routine that would do it correctly.

So I replaced the AnsiCompareStr with my own routine. Feeling quite pleased, I was very shocked when my own routine also lost its own case sensitivity and had the same problem as AnsiCompareStr.

Then it came to me! In the Index of Names, I was joining the surname to the full name to the index info and then sorting on that. Separating the 3 fields was a special character. But since “Surname” and “SURNAME” were both treated as equal, the comparison went past the surname, past the special character, and sorted on the next thing which was the first name. This gave the “incorrect” result that I’ve been working to fix. My solution was to break the fields in separate parts and sort on each in sequence if needed.

What wasn’t obvious about all this was that AnsiCompareStr first compares strings without case sensitivity to see which string is “ANSI” less than the other. If they are the same, then it checks for case differences to break ties. So “Surname” is less than “SURNAME” but “SurnameB” is greater than “SURNAMEA”. This behavior is non-obvious and I never expected it. The documentation of AnsiCompareStr and AnsiCompareText does not make this clear. Whatever! It appears I’ve got it working now.

Using this in Behold, now all differing cases of a single word will now always be put together and any spelling mistakes or typos will be easier to identify.

The third item from Tuesday: Suppressing the printing of subordinate tags to a tag that is marked not for printing was easy to implement. But I will want to make sure that any suppressed tags are noted in the log file. How to do that nicely is a design decision that is tougher than the original task. I may or may not leave this for later.