Copy link to clipboard
Copied
I have a project maintained in version control via SharePoint that I need to pull down into my now-updated RoboHelp 2017. I'll get all the way through setting up my local path and have the files pulled down. However, once I click the .xpj file, it acts like it's going to open and hits me with a "Server busy, switch to busy program to activate and close it."
When you try to do so, though, it only brings up the start menu and doesn't actually take you to a program to close. Any time you click away, it brings you back. Eventually, I have to open Task Manager to kill RoboHelp.
I did already try this registry fix on another computer (I have two and am receiving the same error on both): Msscci with RoboHelp – michal.Log
No dice. I also tried these fixes on the chance they worked: Server Busy error when launching or using Lightroom on Windows
No dice there, either. I have also uninstalled and reinstalled using fresh packages for RoboHelp and SQL Compact Server. Winmerge is up to date. I do not have TFS but I do have Visual Studios 2010 for Office.
Anyone have any ideas? Thank you!
Full error text: "This action cannot be completed because the other program is busy. Choose 'Switch To' to activate the busy program and correct the problem."
Copy link to clipboard
Copied
I have seen this error in the past (long time ago) but not in connection with RoboHelp. As far as I can recall, a reboot fixed it.
See www.grainge.org for RoboHelp and Authoring information
Copy link to clipboard
Copied
I'd have to check with my lead who actually fixed the issue, but I think part of it was tied to ridiculously long file names. She spent the weekend redoing file names and breaking the context-sensitive help (which our application doesn't use anyways).
Thanks!
Copy link to clipboard
Copied
Interesting. It would be useful if you could confirm that.
Copy link to clipboard
Copied
Here was her full response:
"It was a problem internal to the project, but because of the upgrade it was more ‘sensitive’ somehow… aka the long file names. We have been getting away with it for quite some time, but it has been a best practice in both RH and SP to avoid using layers and layers of folders. You and I never changed it due to the old context sensitive help, otherwise it would have been one of the first things to fix when inheriting the project.
Specific answer… I took the project out of version control, moved the files around in the Project Manager so that there were several fewer layers of folders (which shortens the file path), rebuilt the TOC so that those links reflected the shorter paths, and put it back into version control. Can’t be exactly sure why that worked, but I used exactly the same location and permissions, so it can’t be the ‘permissions’ answer from the help desk guy. He was right that SP was throwing an error, though."
Hopefully this helps someone in the future!
Copy link to clipboard
Copied
Thank you. Another reason to avoid long path names rather than layers of folders. Layers are OK provided the overall length is kept in mind.
What is SP?
See www.grainge.org for RoboHelp and Authoring information