[I moved your post into the main RH HTML forum as it really doesn't have anything to do with Webhelp output]
Where is the project located? How is it structured - merged projects, all one big project, folders?
The project is on my C: drive (we use SVN on server for version control). It is one project. The project folder indicates that it has 456 folders.
Hmm...and you say it's bogging down when you type content into a new topic? I've not heard of that one before...
I have encountered this and the bad news is there is no definite answer.
- Have you rebooted the computer since this started?
- Have you deleted the project's CPD file and then reopened the project?
- Does it also occur with the sample projects? Click Open on the RoboHelp Starter page and then click Samples in the ribbon on the left.
- Is there a lot of content in the root of the project rather than the folders? This is more likely to cause processes to run slowly but worth asking.
- Does it occur in any other program?
- How big are the individual topics? I don't think this should be an issue but given the size of the project, perhaps the topics are also outside normal sizes.
As to limits, there aren't any defined limits but at your number of topics I would expect opening the project and running processes (generating etc) to be slow. However, once a topic is open, then it shouldn't affect typing.
Post back when you have worked through the above.
See www.grainge.org for RoboHelp and Authoring information
I have been trying to figure out when exactly I am being bogged down. I have done 1 through 3 of your recommendations, but sill encounter the issue. It appears to happen on one topic in particular that is 913 KB, which is one of the largest, but not the largest. I am able to update the largest without issue.
I noticed that when I try to open the topic that I am having the issue with, it appears to be trying to load ALL images from the project as opposed to just the ones needed for that topic. I am able to update other topics while the problem topic is loading all the images.
Once the problem topic has loaded all the images, it has the 'clocking' issue.
As to questions 4 though 6:
There is a lot of content in the root - each topic folder is there. I have tried deleting some of the folders there, but the project errors on generation.
It is not occurring in other programs.
The largest topic is 1370KB, the smallest is 2KB.
Are your images located someplace other than inside the project's folder structure?
Some are in the folder structure for the topics and some are in the root file. What would cause the image to be saved to the root folder versus the topic folder? (FYI - I use MWSnap for image capture.)
IIRC the default behaviour when inserting images is to copy them into the root & make the link to them there; to get around that, you can copy the file into the desired folder & then make the link through the insert image function (but I could be wrong - I just tend to tidy them up after the fact when my employee puts them in the wrong place).
So it sounds like the location of the images in my project is not a problem if I am reading you right. So I think the question at this point is: Why is one topic trying to open images that are not linked to it and then having issues with updating...
Unless an image is actually referenced or used in a topic, it should not be loaded.
Where or what exactly are you seeing that is leading you to believe this topic is loading up every image in the project?
Sorry I made a bad assumption. It is not all files that are loading. (I thought it was as the length of time for that one topic to load was approximately 20 minutes.) However, I wrote down the image names (which are displayed at the bottom of the RH screen as they are loading).
What apparently is happening is that the files for the topic are being loaded 2 times. After the first load of the image files is complete, it is loading again "Using Cached version..." of the files.
This is the only topic where I am experiencing this issue.
Try creating a new project and import the rogue topic into it. Does it then work OK?
If it does, you have a backup in source control so you could then try copying the new topic into the old project using File Explorer and then opening the old project to see if it behaves with this new version of the topic.
Maybe make a copy of the old topic somewhere outside the project before you start.
I have to say that I think this project has grown way too large. I once inherited a project of some 14,000 topics and even at that size, there were performance issues. I split it up into smaller projects, nothing more than 4,000 topics per project, and used Merged Help. To the end user, it's no different but to you it will make a huge difference. It's no five minute job separating things out but it was worth the effort.
I also helped someone else with a similar problem and she went for the merged help solution and it solved all the issues. She didn't have so many topics and the problem there seemed to be the number of images in one project.
I am curious as to how you have managed to get so many topics. Would I be right in thinking maybe you have separate topics for each field as well as the bigger topics? If so, we came up with a solution that reduced the number of files dramatically. 14,000 became 4,000 without losing any of the information. The customers preferred it as well.
See www.grainge.org for RoboHelp and Authoring information
As per your suggestion, I created a new project and imported the problem topic. The issue is still occurring. (Thanks for this idea.)
In terms of the project itself, there are 2049 topics broken into 89 books. The product being documented has approximately 1500 screens. In most topics with screens, there is typically more than one screen shot and all fields are described in the topic where the screen is shown.
Originally you said there were 47K files, 2K should not cause any problems
such as this.
Can you share the new project with just this topic? See the Contact page on
my site if you can.
This issue was apparently due to system changes across the company and experienced by other employees in different applications as well. But perhaps this post may alleviate many concerns about projects being 'too big'.
Thank you for your suggestions!!