We have a group of 3 writers working on one project. We use TFS 2012 as our versioning system, and are all on Windows 7.
This morning, one of the writers reported that two of the files within the project would cause RoboHelp to crash. This was verified by the two other writers (myself included) for the same files.
I've tried rolling the version of those particular files back to a known working date, but the application still crashes.
This issue is also preventing the creation of any new outputs.
(As a side note: Can anyone recommend any versioning system that might work better than TFS? This really is causing a lot of trouble for us. I literally have to spend at least 10 hours a week trying to figure out technical issues and inconsistencies between TFS and RoboHelp.)
Thanks in advance.
When is Rh crashing? My first thought was on opening the project but if that was the case you wouldn't get the chance to create a new output. I'm thinking you can open the project but generating an existing output causes a crash, correct?
Turning to creating new outputs, do you mean you literally cannot create a new one or that they somehow fail?
If you can open the project, have you tried generating with the rogue topics tagged out?
See www.grainge.org for RoboHelp and Authoring tips
The crashes happen while opening specific topics (not all topics are affected), and when trying to create an output.
We've also discovered that attempting to importing a file also causes a crash.
As for the topics themselves, it seems that only 3 topics are affected by the Open -> Crash route. We're verifying that now. Unfortunately, these are three particularly vital topics.
What's more confusing is that these files were accessed successfully and checked in to TFS on Friday. No one worked on these during the weekend. On Monday, the problem started happening.
Edit: Unfortunately, we can't create the project with the items tagged out. This project has other issues which, unfortunately, preclude us from using tags at ALL. I'm trying now to recreate the project in hopes that (a) it fixes this issue, and (b) we can use tags again in the future. (The document, when I inherited it, was quite broken. I've made some improvements, but clearly not enough.)
Thank you for your time. It's much appreciated.
As it is only affecting three topics, one thought would be to simply remove the offending topics from the project. Copy them to a folder somewhere on your drive. Then delete them from RoboHelp. Create totally new topics. Then display them from the folder using the browser. Copy and paste the content from them to the new versions.
Actually I tried this last night, but the system crashed. I wasn't doing the broken files individually (though this was my next step), but en masse. I figured it was the number of files that did the import process in, not any specific file. I may have been wrong about this.
Interesting. I believe I found the answer. This was a tricky one, actually.
Here's what I did:
So it was definitely something in the code.
I opened the file using Notepad, and discovered that something weird happened with one of the variables:
<?rh-udv_start name="ApplicationName" ?><?rh-udv_start name="ApplicationName" ?>ApplicationX<?rh-udv_end ?><?rh-udv_end ?>
There was a variable tag embedded inside a variable tag. I removed the doubling so that only this was left:
<?rh-udv_start name="ApplicationName" ?>ApplicationX<?rh-udv_end ?>
I saved the file and it loaded just fine in the system. I did a search in the system for <?rh-udv_end ?><?rh-udv_end ?>, and discovered that 45 files were affected. (This was a relief, as the help file contains over 1800 topics.)
Why It Happened
If you're wondering where that bit of code came from, I'll have to take the blame for that. Our company just went through a re-branding. Whoever worked on this help file before wasn't really using variables. So I used the global find/replace to search for the old branding name and inserting the new branding name, plus the code to make it a variable.
Replace: <?rh-udv_start name="ApplicationName" ?>ApplicationX<?rh-udv_end ?>
Unfortunately, it looks like whoever worked on the help file before THAT did use variables, but those instances were so rare that I hadn't really run into many of them. I thought I had converted the existing variables using the User Defined Variables pod before doing the global find/replace, but I guess I didn't.
So now, I'm cleaning up these files, using Notepad++.
Thanks to all for your help. Without your assistance, I wouldn't have been able to find this rather tricky issue.
Appreciate the heads up! I'm sure it will help others that may come along later with a similar issue.
As for your TFS question: TFS is one of the more stable and reliable source control systems for RoboHelp. SharePoint works as well, but is very limited. RoboSource Control, SVN and the like are very trouble prone. You can use source control outside of RoboHelp (manually checking out the files) but that adds a lot of overhead. So not a really good alternative.