Well, it seems that way. I’ve been getting lots of great feedback and I’m constantly finding a few more tweaks to add and improve the Help Builder Interface. But man is it sucking time at the moment.

I found out yesterday that I accidentally uploaded a bad build to the server. This build that wasn’t supposed to go out had a very obvious bug in the Class/Database importer that caused a failure as soon as the import option was selected. I had built a test install for running on a couple of different installs here as I always do before uploading a new build when I found this obvious error.

I fixed it rebuilt the install, but didn’t recheck the full install. Uploaded it and somehow the bad build ended up online anyway. Worse, I saw the bugs coming in the bug reporter the next morning, and I immediately knew what the problem was. So I rebuilt the install project one more time and uploaded it again.

Turns out this still didn’t fix the problem – more reports from new downloads were coming in with the bad version. Aaaaaaaaaaaaaaargh. I turns out the FTP client didn’t replace the file on the server. It didn’t give any warning but the file was not replaced properly so downloads continued to go down with this bad build.

This is particularily embarrassing, since today a big rush of MVPs came in to get download information to Help Builder. The solution is actually simple (if you are running 4.0512):

Go to the Help Builder Help menu and Check for Latest Version which will grab the latest version which should be 4.0514. I’ve also updated the main installer again and made sure that it’s the right date by deleting first this time around.

I’ve also spent what I thought should have been a quick 15 minute job cleaning up the way Help Builder calls the 1.0 version of the HTML Help Compiler. Currently Help Builder uses some high level language commands to execute the compiler which brings up an annoying DOS window. I finally decided that I need to do something about this somewhat unprofessional view so I switched to using the CreateProcess API. Getting this to work with with waiting for completion and sending output to the a redirected StdOut file took a while to get right however – another evening sunk. It turned out this was easier to do by writing a small block of C++ code and sticking it into a DLL rather than coercing Visual FoxPro to try and work through the various structures required to make this happen. What really made this difficult was the fact that I ran into several articles that demonstrated how to do this in various languages, but none of them actually worked because they neglected to set inheritable security attributes. Ugggh… what a nightmare.

As a side effect of this forced update above this fix is now included in the update which makes for a more smooth Help compilation process.