Recently upgraded from RoboHelp 2015 to RoboHelp 2017. Normally, a project created in the older version updates automatically simply by opening the .xpj file in the newer version. However, RoboHelp 2017 hangs in both Windows 7 and Windows 10 when trying to open the .xpj file created in RH2015.
I've tried all the old stand-bys: rebooting the computer, giving the project hours to open in case it's trying to update, attempting to open projects with a smaller number of files, re-installing RoboHelp on the computer, and installing RoboHelp on a different computer. The end result has been the same. After about 3 seconds, the Starter screen freezes and dims slightly, and RoboHelp continues to churn until I kill it in Windows. I've noticed two messages in the status section at the bottom of the screen: either "loading xxx.xpj" or "Loading DB info."
I also tried deleting the .cpd file and opening from the .hhp file. Same outcome.
One other observation: Typically when updating a project to a new version of RoboHelp, a pop-up displays saying that the project was created in an older version and offers the option to update in the new version. No popup displays before the system hangs.
I am able to create a new project in RoboHelp 2017, so the app seems to be working as long as it's not updating older files.
Anybody else encountered this issue and come up with a work-around?
You don't get a warning because projects can be opened in either version.
See The RoboHelp Tour on my site for more about that. (You mustn't edit the
new layouts if you revert to 2015.)
RoboHelp opens OK but it hangs when you try to open a project, correct?
Is it the same with the sample projects?
Did you have admin rights when installing?
Yes, RoboHelp 2017 opens, but it hangs when I try to open a project created in RH2015. It doesn't have a problem with .xpj files created in RH2017.
I did have admin rights when installing, and I also tried running as an administrator to see if there'd be a different outcome. There wasn't.
It shouldn't make a difference which version it was created in.
Are you basing your statement that projects created in 2017 open OK on
trying the samples or one you created?
Are the 2015 projects local?
Do you still have a machine with 2015 installed?
I tried samples and created a two-topic project in 2017 that opened. Something is definitely getting lost in the translation from 2015 to 2017.
The projects are all hosted locally, but I use git/github for source control.
I do still have 2015 installed, and all the projects open without incident in 2015. However, if I open the .xpj in 2015 after an unsuccessful attempt at opening it in 2017, the Project Files folder in the Project Manager is empty. No files have been deleted from the project directory, but the project no longer recognizes them. Oddly, the Default TOC is saved in the project, but all master pages, outputs, and conditional build tags are missing.
Fortunately, I've been working with duplicates of these projects when trying to open them in 2017, so I haven't lost any work. I was hoping to employ some of the new features, but that will have to wait until a solution to this problem presents itself.
My Spidey Sense is tingling and whispering in my ear that GitHub may be playing a role in this equation.
I'd try creating a small project in 2015 Release that is NOT in GitHub. Just three or four topics. Add them to the TOC and Index and create a small master page and suchlike.
Make a copy of it.
Now open one of the copies in 2017 Release. I'd bet it opens fine with no issues.
Then add the second copy to GitHub. Then try opening that in 2017 Release.
I'd bet that this time around you will see an issue.
How exactly did you add the projects to GitHub? Note that only certain project files should be added to Source Control systems. If you add the entire project, you will encounter issues.
The plot thickens. The small project created in 2015 worked in 2017. Added the copy to GitHub. And it also worked in 2017.
I would be very surprised if git were the source of the problem here. We deliberately made sure that our git integration was a raw commit of the files, as we know how susceptible Adobe files are to corruption when they're handled by non-Adobe products or systems. All the git metadata files are hosted in a separate directory from the robohelp projects. While it is possible to view the source code for our project files in GitHub, we do not alter any of those files outside RoboHelp.
As for this experiment, I did not go to all the trouble of recreating the custom screen layout that I use in all our projects. I'm wondering if the problem might be related to that, or to our default.css file, which uses custom fonts imported as baggage files. If either of those are at the root of the problem, then I might just have to stay with 2015.
Custom Screen Layout?
Can you please expound on that?
Note that I'm not thinking it's related, more curiosity than anything else.
We took one of the out-of-the-box screen layouts for HTML5 and performed some extensive customization, swapping out icon files, using proprietary fonts, and tweaking it (always using the layout editor within RoboHelp) so it matches our corporate look and feel and reflects the same design aesthetic as our products.
Hopefully you exported it out so that it's as simple as importing it back into any project where you want the same look and feel!
It looks as though it might be related to some customizations I made to default.css. I took the sample project that worked in RH2017, pasted our custom default.css into the project folder, and tried to reopen the project. It didn't open. So I pasted in the default.css from one of the sample projects, and then the project opened. Has something changed in the way RH2017 parses that file? Odd that 2015 would open fine, but default.css would cause 2017 to hang.
Hmmm, I'm not a member of the RoboHelp development team so I can't say for certain.
I suppose one way to know for certain would be to take a project that you have created that does NOT have the CSS, open it in RoboHelp, then attempt to import the CSS into the project and see if it makes 2017 Release gag.
If so, I'd consider it's likely a bug and should be reported to adobe using the link below.
That's exactly what I did, and that's precisely what happened. A bug report it is!
I suppose in this case the logical next step would be rather painstakingly slow. That would be to carefully edit the CSS by removing (or adding) one segment at a time, then repeating the import process.
One way you might start (should you choose to try this) would be to take the basic default.css RoboHelp creates, then compare it to the one giving you fits. You could likely skip any elements that are common between the two and focus on elements that only exist in the one giving you fits.
Just a thought... Rick
I wonder if this would work if the finger of suspicion is pointing at the layout.
In File Explorer, delete the layout in the !ScreenLayout! folder, then try to open the project in RoboHelp 2017.
Obviously with the usual health warnings about backups and so on.
If the project does then upgrade, copy it again, close it and try adding the layout folder back in from a backup, an export from RoboHelp 2015 or similar.
See www.grainge.org for RoboHelp and Authoring information
To anybody who might be interested, I tracked down the culprit. We have been using @font-face in default.css to embed custom fonts in our output. Removing @font-face from default.css resolves the issue of RH2017 hanging when trying to open a project that opens in RH2015. Unfortunately, it also removes the custom font. Looks like I'll be opening a new question and, potentially, filing a bug report.
To be clear, that worked in 2015 but fails in 2017 or just fails the
upgrade but then works again?
The @font-face code in default.css worked in 2015 and crashes 2017. If I remove the @font-face code from default.css, the project successfully opens in 2017. If I re-add the @font-face code in 2017 to default.css after opening the project successfully, the project crashes and won't reopen.
Try creating a new project and testing with the default CSS in that. I can
draw Adobe's attention to this but first I need to know it is a pure CSS
and not one you have edited in any way.
Might have something to do with the specific font involved?
I just edited a CSS in a 2017 project and added this code:
Seemed to work fine and project opened up without issue.
It's not the specific font that's the problem; if I do the font-face code as you present it here, the project opens.
However, I have four different formats for the font to make it display in the different supported browsers, and when I concatenate the url/format params in the src: string, that's when the project gags on default.css.
This worked in RH2015:
|src: url(amplify.eot) format(eot), url(amplify.woff) format(woff), url(amplify.ttf) format(truetype), url(amplify.svg) format(svg);|
Definitely getting closer here...
Wondering what would happen if you omitted that final semicolon following the closing curly brace.
So instead of ending with }; just end with }
Already tried, and it makes no difference.
I've also tried with/without single/double quotation marks.
Troubleshooting is fun, but not on a deadline...
I've spent my spare time troubleshooting, and here's the problem: RoboHelp 2017 will not operate if you list more than one font format in @font-face in default.css.
So this works in both RH2015 and RH2017:
src: url(amplify.eot) format(eot);
But this crashes RH2017:
src: url(amplify.eot) format(eot), url(amplify.woff) format(woff), url(amplify.ttf) format(truetype), url(amplify.svg) format(svg);
The .xpj file hangs if you try to open it after modifying default.css; the project crashes if you try to generate output after adding the different font formats to default.css and saving.
Time to file a bug report?