New Topics Not Appearing in Contents Pane

[K-Clark]

Here's hoping someone else either knows how to fix the following, or what's causing it at least.

Every time I create a new topic or folder, it doesn't appear in the list of contents until I either close & reopen RoboHelp or restart it from the menu. I've tried deleting the .rh folder while RoboHelp is closed, then opening the project again, but no dice.

Any thoughts?

Thanks!

[Peter Grainge]

You haven't said which version of RoboHelp you are using. Please always start a thread with this information. Please go to Help > About and include the full version number.

It's obviously 2019 or 2020. If 2019 you should have Update 14, for 2020 it's Update 6.

Is the project local or on a network?

Does the same thing happen if you try the About RoboHelp sample project in Documents > My RoboHelp Projects or any other project you have (create a new one to test if necessary)?

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[K-Clark]

Hi Peter! The version of RoboHelp is actually Update 11 for RH 2019.

I just tested other projects (in the same network folder) that previously didn't have this issue, and now they're experiencing the same thing. In the locally-stored sample projects, though, everything is working as expected.

Seems like it's related to the network location, but it doesn't occur on other computers with the same version of RH19.

[K-Clark]

Correction--other computers are now having the same problem, though they weren't previously.

[Peter Grainge]

When the ability to store projects on a network drive was introduced with the new UI, Adobe did caution that it was dependent on the speed of the network. That does seem to be the issue here.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[K-Clark]

I'll check with our IT team to see if this is the issue--no idea why it would suddenly become a problem the last few days, when before everything worked as expected. Thanks for giving me a next path to look down for a solution!

[Peter Grainge]

I think the fact that it's occurring with all network located projects and not when the same project is local is a good pointer to the network being the issue. Keep us posted.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[Amebr · Accepted solution]

I know many companies have policies about storing source files on the network for backup purposes, which hasn't historically worked very well with Robohelp.

The following are my suggestions for Robohelp Classic, but which may still be valid for New UI, given your issues seem to be network related. 

1. If you have multiple people working on the projects, I recommend using source control to store the projects. This means the project source is on the network and backed up, but you make changes on a local copy (and the check-in process copies your changes to the network, basically). I used to also recommend, for RH Classic versions, the local source control workspace be configured somewhere like "C:\Manuals", not inside your Windows User folder, as there were local paths stored in the source files that caused problems. I can't offer a recommendation in this regard for New UI, not having used it properly, nor with source control. Just keep it in mind if you go this route.

You can also use this method if there's only one writer, but I think only go this route for one persion if you have developers already using a source control tool, so you have technical support when something goes wrong. Troubleshooting when you have no idea about source control systems is a sure fire way to have a nervous breakdown. 🙂

2. If you only have one person accessing the projects, work on the projects locally, but upload a zip file to the network every night/week depending on how frequently you make changes, and after every production release. Have a good naming convention so you can identify nightly backups vs production releases, and go through regularly to delete old nightly backups. You'll need to make a call for your situation how much to keep - a month of backups or until the next production release, for example. You'll also need a policy for cleaning up/archiving the production release backups, depending on your corporate policies and disk space.

3. If you have multiple people accessing the projects but can't use source control for some reason, I still recommend working locally and storing zip backups on the network. Constant communication is the key for multiple people working on the projects. The backup principles are the same, but you will need to talk with colleagues constantly so you know who is working on what. I highly recommend that only one person works on a project at a time, and you download the latest zip from the network, after confirming with your colleagues that no-one else is working on it, or they confirm they have finished uploading their latest changes to the network.

[K-Clark]

Thank you for this very thorough set of advice! I will coordinate with my IT team to see if source control is possible, and if so, whether it fixes the bug.

If not, we'll probably follow one of your other suggestions. Thanks again!

[Peter Grainge]

I think what Amber is saying is that with source control you would be working on a local copy of the project. Because what you are working on will be local, then you should not have the problem as you have already indicated that the problem does not occur locally.

What you are facing is not a bug, rather an issue with network latency. As it was working it may have just been a temporary glitch or some change IT have made.

________________________________________________________
My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.