This content has been marked as final. Show 4 replies
First, I don't know the answer so I am just throwing out ideas.
You refer to webhelp output (or webhelp pro) as if they are interchangeable. They are not. WebHelp Pro needs RoboServer so unless you have that, forget it.
It makes me wonder if you have generated both outputs to the same location and created a bit of a mess. Have you tried deleting everything from the output folder and creating a completely clean build?
Is the help sitting on a server or being installed locally? If it is on a server, why include the mark of the web?
Thanks for your reply. I sort of recall having this conversation with you a while ago. Indeed I realise that webhelp and webhelp pro outputs are different in nature: I use the webhelp output to place the local help system on the disk that we deliver to the client and place the webhelp pro output on the server with the RoboHelp server for our customer support site.
Both outputs are compiled in clearly distinct folders and there is no overlapping between the two.
The reason why I mentionned both outputs is because I am getting the same type of pb with the same symptoms when adding the mark of the web. Naturally, for the webhelp pro this does not matter as I do not add the mark of the web for server based help (which makes me wonder why Adobe has added this option for this output and more importantly, why it is selected by default) but just mentionned in order to indicate that this is not specific to the webhelp output.
This said, my point was that when adding the mark of the web option, I get the error described above whereas when it is not added, everything works fine (apart from the fact that the active content is blocked and the user has to explicitely allow active content to be displayed). Therefore it seems that the inclusion of this option is generating some type of error and I hoped that perhaps someone else had encountered it and found a workaround as I am unable to find a viable solution to this.
Something was telling me it was familiar. You've cleared up the concerns I raised.
Next idea. Create a new project with just a couple of topics and publish it to the same servers. Do you still get this problem? Trying to establish whether the problem is project specific.
Ok I think I pinpointed the pb. I was not looking at it from the right perspective.
You were right by thinking it was project specific.
All the projects where this problem arose had one same commonality that I did not see upfront: they all had the presence of at least one broken link reported by RH.
Because these broken links are not broken at runtime, I did not think that it would be in issue.
Fixing the "falsely" reported broken links (by creating the topics in RH and redirecting the user to the initial file that was intended) corrected the issue.