Sorry, but my crystal ball is broken and my psychic skills are sub-par. So I'm unable to divine the output type you may be using.
If it's a CHM or Installed AIRHelp output, perhaps the developers are mistakenly pointing to an older version of the CHM or AIRHelp package?
If it's a WebHelp, FlashHelp or Web Based AIR output, you need to manually remove those topics from the server.
Helpful and Handy Links
oops! Pardon me for the lack of details.
The output is webhelp.
So if the unused files are in the directory with the files I'm using in the project, I have to remove the unused files?Are there any other files that I have to edit as well.
I removed all the topics from the Robohelp HTML project directory in our Accurev configuration system. I recompiled and sent the files off to our developers overseas. They are still seeing TOC and index entries to the topics that I removed in the help that has been indicated with my company's product.
I noticed the HHK still contains the keywords for the index and that the project manager shows the HTML topics with a red X through them to indicate they were removed. Should/Can I delete the red X'd topics. Index entries? Will it help?
Any suggestions? I want to make these topics go away!
I meant integrated with my company's product!
In my earlier reply I stated that you will need to manually remove files from the destination location. The fact your developers are still seeing them is suggesting that wherever they are pulling files from is not being updated. This could be a source control system or it could be a rogue directory they are pointing at that you are unaware of.
I hate to get into finger pointing sessions, but if you generate and the TOC looks and behaves as it should on your set, then you upload that set of files somewhere else and you have no control over what happens after that, it's time to suggest the developers review the process from your handoff forward. I smell something fishy and a breakdown on their end.
The problem here is that developers often have a God mentality in that they are generally more technical about program operations and it's difficult to get them to even begin thinking they may be doing something incorrect on their end. In their eyes, it's yours, it's broken and they expect YOU to fix it. So what you have to do is prove to them that it's not "broken", until they get hold of it.
I feel for ya, I really do!
Helpful and Handy Links
Thanks, Rick. You were correct. We are in the process of rebranding the third-party help files with our company logo and background. The developers were merging old help files that contain new branding with my new help files so they could rebrand my current help with our company theme and background. The result was that all the files that I removed, were being brought back in with the old files.
Fortunately, I have had the backing of the product architect to find where the problem lies and fix it. Unfortunately, I have to figure out which files contain the branding and replace them because they think it's better that I send the developers the complete project, branding and all, rather than them trying to add the branding.
Cheers to you,