Did you paste the folders to the WebHelp5Ext or to the same name folder within? The latter is not the correct procedure.
You have to drag the supplied folders to where I have shown, you do not paste them over the top of the old template_skin and template_skinpreview folders. When you drag to the correct location, you will be asked if you want to merge the folders, confirm you do.
If you have dragged to the old folders, sub-folders will have been created that you need to reverse out.
The template_skin folder should not have any sub-folders.
The template_skinpreview folder should have a template_skin sub folder but that should not have any further sub-folders.
The patch does work once you have regenerated so I am pretty sure that is where you problem is. If you are not sure about all this, you may want to get IT or a developer to assist. Whilst it will not impact this problem, also make sure you have applied the recent patch.
See www.grainge.org for RoboHelp and Authoring tips
Message was edited by Peter Grainge to clarify first paragraph.
I can see where duplicated folders within folders would be a problem, but that is not the case here. I pasted the two folders to the WebHelp5Ext fold, so there were no duplicated subfolders.
Just to be sure that I did everything right, I went back and deleted the template_skin and the template_skinpreview folders from the WebHelp5Ext directory. Then I returned the original
template_skin and the template_skinpreview folders to the WebHelp5Ext directory. (I had copied these off to another location at the beginning of this process.) I verified that the files contained in these folders were in fact the "old" ones by checking the whtbar.jsfile date (7/4/2012 in the old folders and 4/10/2013 in the new folders). Next I dragged the folders supplied by Adobe to the WebHelp5Ext directory and answered the merge and copy/replace questions. I then confirmed that the file date now displayed was the "new" date. But when I opened RH and regenerated the project, I still observed the undesireable IE10 behavior.
Other troubleshooting efforts:
- I've reviewed the properties of the "supplied" files to make sure that none were set to "Read-only" (in case this made a difference). None were.
- I've cleared the IE10 cache several times, to no avail.
- I've reset my IE10 settings to the program defaults and restarted my machine. Still no go.
While my situation may very well be the result of "user error," I can't see what I'm doing wrong. Any additional suggestions will be appreciated.
In order to rule out a user error, try the following:
1. Open whtbar.js and check line 709. It should be:
else if(sType=="hide2" && navigator.appVersion.search("MSIE 10.0") == -1)
2. Open whskin_frmset01.htm and check line 108. It should be:
if (oFrameset && navigator.appVersion.search("MSIE 10.0") == -1)
Do the lines in both files match the above text?
For the whtbar.js file in the ...\WebHelp5Ext\template_skin folder, the referenced information is indeed found on line 709. However, in the ...\WebHelp5Ext\template_skinpreview\template_skin location, the referenced info is found on line 706.
As for the whskin_frmset01.htm file... I do not have a file with this name, and this is not one of the "supplied" files. Did you, perhaps, mean whst_frames.xml? If so, in both affected folders, the referenced information is found on line 124, not 108.
So what does this tell us?
Sorry for the confusion, I was checking to see whether the could would be present in your output (hence the whskin_frmset01.htm instead of the XML file).
If the code is present in your output, it seems that you applied the patch correctly. And thus it would rule out a user error. From what I can see know, it that this patch doesn't fix IE10 for WebHelp Pro.
After muchmore testing, I've come to the conclusion that the issue is somehow related to my machine and our corporate network--not the fix or whether the output is generated as WebHelp or WebHelp-Pro. In a nutshell, when my machine is connected to our corporate network, my projects do not display correctly in IE10--regardless of the WebHelp output. Inexplicably, on a co-worker's laptop, connected to the same network, the projects work as expected. Then, when I connect to the Internet via a non-corporate wireless network or through a VPN, the projects seem to behave perfectly in IE10, on my same machine. (Cue the Twilight Zone music.)
I'm not sure what's going on, but at this point it appears to be a matter for my IT department.
Thanks Peter and William for your kind and prompt assistance!
For most people the IE10 fix will work. There are two known scenarios where it will not.
See www.grainge.org for RoboHelp and Authoring tips
So I'm not normal.....
How would one go about enabling the js by adding webhelp as a trusted location in IE10 settings. I don't know how to do this (but I really tried)....
Our webhelp docs are not stored on a server at customer sites, so this is a major issue.......
Thank you, Peter, for looking into this issue so persistently.
In most instances, my WebHelp project does display correctly (with the Adobe IE10 fix), and in those situations where it doesn't, IE10's Compatibility View seems to be an easy workaround. I do, however, appreciate having the information about those two problematic scenarios you describe. We will add your troubleshooting tips to our support wiki.