4 Replies Latest reply on Oct 10, 2007 8:48 PM by Cro1410

    Mark of the web

    Cro1410 Level 1
      I intially thought that it was my computer that had a problem until clients gave feed-back that they were getting the same problem.
      This is the pb:
      when I include the mark of the web on the webhelp output (or webhelp pro), when the help system opens the following error message is systematically displayed:
      "A runtime Error has occured.
      Do you wish to Debug?
      Line: 225
      Error: Access is denied"

      After a bit of debugging, it seems it the WHUTILS.JS file that is affected. Apparently the msxml3.dll cannot be accessed and that generated the error.
      I tried all the possible fixes from the net for msxml3.dll, and nothing seems to be giving me a solution.
      I am working with XP SP2 with IE7 browser and using RH6.
      Any ideas?
      Many thanks,
      Chris


        • 1. Re: Mark of the web
          Peter Grainge Adobe Community Professional (Moderator)
          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?

          • 2. Re: Mark of the web
            Cro1410 Level 1
            Hi Peter,
            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.
            -Chris
            • 3. Re: Mark of the web
              Peter Grainge Adobe Community Professional (Moderator)
              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.

              • 4. Re: Mark of the web
                Cro1410 Level 1
                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.
                - Chris