I’m always up for a challenge, and I’ve always enjoyed the challenge of a GEDCOM torture test. Most Genealogy programs claim they have no limits, but eventually every program will run out of something -array capacity, memory or time or maybe it just wasn’t written to handle a certain type of complexity.
So I was excited when Tamura Jones posted three GEDCOM torture tests along with how a good number of programs did against them. (Note: Internet Explorer can’t view Tamura’s site. Try a browser like Firefox or Google Chrome)
I was looking forward to Behold’s results. I was not happy when I saw Behold had only passed one of the challenges. I pride Behold in its ability to read all flavors of GEDCOM, and this indicated something needed to be fixed. Knowing that not a single program passed all the tests did not make me feel any better.
So as part of this version’s upgrades, I decided to include a few of the things on my “Tamura Jones” to do list - not the least of which was to easily read all the torture test files. That is now done. I hope Tamura will check it out and verify that I have actually done so.
I’ve made a number of improvements and fixes in this version. See the complete list on Behold’s Version History page.
I’m very pleased with my progress so far during the beta. I’m actually getting through all the bug fixes and changes almost as quickly as I had hoped I would. An April release date for Version 1.0 is still my goal.
Leave a Comment
When I virtualized the Everything Report, I created one routine to write out the various parts of the report. It could send the results various places: to the Report itself, to the HTML export, to the Rich Text File export, or into plain text for the purpose of simple searching.
So I figured I could reuse that routine and simply add a new option to write to the log file. The file information in the Everything Report was something that could then easily be sent also to the log file - so I thought.
It took about 2 hours to set up and then - yuk! It looked terrible.
The Everything Report, HTML and RTF are all nicely formatted and indented. Text for the search doesn’t matter since you don’t see it. But the log file is plain text with no formatting at all. The stuff was jammed together, not indented, had hugely long lines and basically was impossible to read. I spent another couple of hours trying my best to automate the formatting and make it look reasonable.
That wasn’t going anywhere. So I took it out, and in a half an hour, I added custom append to the logfile routine that now does it much nicer.
The sexier way is not always best, so it sometimes pays to take your lumps early and go on.
Leave a Comment
There was another feature I used to have in Behold that just has been knawing at me. It actually is important that it be put back in now while the time is ripe.
Basically, when Behold reads a GEDCOM, it may find problems with the GEDCOM file. I’ve now added the listing of the problems to the file information in the Everything Report. But what if Behold is interrupted or does not get to that point? How about more detailed information that isn’t appropriate for the file information (such as line references from the GEDCOM), or maybe just some warnings about the GEDCOM that you really don’t care about normally, but may want all the detail for.
Well this should all go into a log file that is created when a file is read. The fact that there is a log file at all will add to your security to know whether Behold is or isn’t detecting something.
I had two different interfaces for a log file. At first (way back in 2005) there was one I really liked. The top part had the GEDCOM files with a tabbed interface. The bottom was the log file. It was meant so that you click on an log message, and the line could be brought up in the pane above. But back then, loading all those GEDCOMs into TRichView windows was expensive in terms of performance. I didn’t have the Virtual TRichView back then - so I took it out and I put in a simple writing of the log to a file. That happened in version 0.98.8 alpha, 28 Jan 2007.
I then decided for version 0.98.9.5 alpha, 19 Nov 2007 to not print the log file altogether. This is the decision I am now reversing.
Putting it back in really isn’t too hard. All I have to do is compare the differences between version 0.98.9.5 and 0.98.9.6 to see what the log file code was. I started that two days ago, and it took about 15 minutes to get the code in again.
The harder part was my “AppendToLogFile” routine. It was written with Delphi 4 before Unicode and didn’t work with Unicode. I puzzled how to get that working and searched Google, but after two hours I wasn’t there. So I went back to my friends at StackOverflow and asked “How can I get this File Writing code to work with Unicode (Delphi)“. With that help, it’s now just two days later and the core code is working again.
There is no standard way to write a log file, so it’s up to me. Most genealogy programs do not do a good job with theirs and many don’t even produce one. Behold is already fairly decent at determining problems with GEDCOM files, so its log file should turn out to be quite useful when it’s needed.
Leave a Comment