It might be worth renaming the projectname.pss file and then opening the project and compiling. If this doesn't work, try creating a new SSL (do not duplicate the existing one). Let us know if either of these work.
I renamed the .pss, and tried to compile the "defective" condition. RH8 took a few extra seconds to build itself a new .pss, and then it crashed exactly as previously described.Then I specified a different name for the .chm file (I think that's what you meant by "a new SSL"), and it crashed as previously described. Then I tried to verify that I can still compile the "good" condition, and when I started RH8, there is a message that Dr. Watrson Postmortem Debugger failed, and now I can't start RH8. So things are going from bad to worse and I don't know what to tell you. Let me panic for a while and try to get RH8 running, and I'll post again.
After reboot, RH8 is running.
I can still compile the "good" condition.
In addition to the Output View details that I typed above, a *successful* compilation also includes something like:
Finished preparing in 67 sec(s)
Generating HTMLHELP (126.96.36.199)...
Finished compiling HTMLHELP in 113 sec(s)
In other words, I'm saying that compiling with the "bad" condition causes failure AFTER "Updating files..." and BEFORE "Finished Preparing in 67 sec(s)".
What I meant by "creating a new SSL" was right clicking in the Single Source Layouts pod and selecting New Layout. From the resulting dialog, select the required output type and set its properties the same as the other one. However the Dr.Watson reference may give us more of a clue as to the problem. See this link for further info.
I changed the output to WebHelp and it crashes just the same.
As for the microsoft KB article about Dr. Watson, I'll read it, but I don't know .....
I wish I could get the Output View to name the file that RH8 is choking on. ??
Assuming you have also tried deleting the CPD file (after backing up) you may have to resort to the half and half approach as below but first try two other ways of finding the rogue topic.
- If you right click the condition and look at its Properties, you will see the topics using it.
- Use a multi file find and replace tool to search for the condition. The RH supplied tool should be good enough for this purpose.
If no joy...
THE HALF AND HALF METHOD
- Zip up your project so that you have a backup copy that cannot be opened by mistake.
- Trash half the topics from your project and compile again.
- If the problem is not fixed, trash half of what is left. Continue until it compiles. The problem is in the last batch of files you deleted. See 4.
- Now unzip the backup and trash everything except the batch of files identified as containing the problem. Keep the zip safe as you still need that.
- With the identified batch, repeat the trashing and compiling until you find the rogue topic.
Sounds worse than it is.
See www.grainge.org for RoboHelp and Authoring tips
The trashing technique is exactly what I was thinking about trying, so now I have confidence that I can think like Master Grainge. More better, I will start by trashing only the .htm files that changed since the most recent successful compilation. I'll let you know.