This content has been marked as final. Show 6 replies
Hello Jim -
What's the problem?
Ok, here goes. The problems are several:
First, a RoboHelp author (Author A) who was just recently granted admin rights WITHOUT reinstalling RoboHelp can now view:
WebHelp output locally created by another RH X5 author (call him Author B), who was also granted post-install admin rights)
WebHelp output on a network drive (created by Author B)
WebHelp output from a new project he (Author A) created locally
The same WebHelp output on a network drive.
Author B, even though he was granted admin rights after RH was installed, just like Author A, cannot view the table of contents of ANY WebHelp build regardless if he created it or someone created it, can't be viewed locally or on a network drive. He sees a "blank" pane where the TOC should be. Navigation buttons (TOC, Index, Search) work fine. All of these projects are built using the DHTML > Java applet > Pure HTML method.
Authors C and D DO NOT have admin rights. They can both build WebHelp projects, but both of them:
see an IE script error related to "whskin_pdhtml.htm" when they try to import a skin that I've created previously and used successfully.
Error: Automation server can't create object
URL: file://C:\Documents and Settings\username\Local Settings\skinpreview_0\whskin_pdhtml.htm
Do you want to continue to run scripts on this page? (Yes/No)"
Authors C and D also cannot view the TOC of ANY WebHelp project, just like Author B.
In researching the whskin_pdhtml error, I found a solution at http://groups.google.com/group/macromedia.robohelp.webhelp/browse_thread/thread/b296a5cf83 189ed6 but it didn't work. Seems like a very rare error.
I'm leaning towards a security issue, but I don't know. Funny thing is, if what the google groups reported is true (that this error "suddenly" appeared in November 2007, then we could maybe attribute the whskin error to an IE patch, but which one? I'm getting REALLY tired of having to find fixes to our problems every few months after some stupid IE patch wreaks havoc with something else - we had a problem related to generated output and WinHelp/CHM last year that was directly related to a Microsoft Security patch.
I'm thinking about saying to our support group "Ok, give all RH authors admin rights, then uninstall/reinstall RH, then STOP any automatic Java updates forever (that's another issue), then we should be ok." But based on what I've found so far with Author A and Author B, I'm not sure admin rights are really the problem. And, what if another IE patch comes along, and messes with DHTML, Java plugins, etc?
Think I can make a stronger case for RH 7 upgrades?
This is getting really old. Sorry to vent.
Thanks for reading.
Hello Jim -
You're preaching (venting?) to the choir when it comes to Microsoft, IE, security and patches (is today patch Tuesday and tomorrow reboot/debug Wednesday?).
Have each (A, B, C, D) open their Internet Properties window (from Control Panel or IE > Tools > Internet Options) and compare everything!
Let us know what you find as this appears to be a browser setting issue related to allowing scripts to run.
Here are a few steps you should take. Linux Rules probably will add some.
1. Give user A and user B local admin rights.
2. With each logged into his/her machine, uninstall RH.
3. With local admin users A and B still logged in, install RH X5 and be sure you get the add-on to bring it up to 5.02. Upgrade to RH 7 is desirable, but not absolutely necessary unless you start using Vista.
4. Remove local admin rights from A and B.
Given the age of RH X5, I suspect you have upgraded MS Word and might not have reinstalled RH after the upgrade. That would be another, compelling reason to do a fresh installation now.
It's hard to say how many of your system symptoms will clear up, but I'd lay money on 90%.
Added conditions: Don't expect C and D to be successful building a project unless they have the same status as A and B on their PCs, with RH installed locally.
Don't try to put the RH project on a network drive for everyone, unless you use version control on the network, and each checks out the entire project to work on his/her PC.
Post back if you're still having problems after doing this.
GEWB and Harvey,
Thanks for the info. I'm going to put in the paperwork to get thing going today.
A couple of this I've also noticed around here. They told me that Author A had admin rights and told me how to check (right click My Computer | Manage | Local Users and Groups | Groups | Administrators - should see a username listed there), but when I did, his username wasn't there. Consequently, that explained why he couldn't install a new JRE and/or change his system variables, since he had two of the same JHHOME with different values. Oh yeah, we're also dealing with some JavaHelp issues. So I need to verify that admin rights have truly been granted. Great...
As far as having people access existing RH projects from the network: for my testing, I'm only having them try to view the output in the !SSL folder, not by opening the project
For the IE | Tools | Internet Options, I checked mine against those of Author B ("admin" rights, but couldn't see a TOC), and had him modify his to match mine. Still had problems.
I'll let you all know what happens.
As far as having people access existing RH projects from the network: for my testing, I'm only having them try to view the output in the !SSL! folder, not by opening the project.
It sounds like you have the project and/or the !SSL! folder on a network. Let's check some basic assumptions.
1. The project is on a local hard drive, the one where the user had local admin rights when RH was installed on that local hard drive.
2. WebHelp is being generated in this project to the !SSL! folder within the project directory on that same, local hard drive.
In other words, up to this point, we're talking about one user working on this project and nothing on a network.
Please confirm. We can't really sort things out for other users until this is established.