I have found a partial solution to the problem of the unwanted Glossary button. In the skin editor, I removed the default image reference for the Glossary button and replaced the word "Glossary" with a blank space.
Who knows -- maybe this is how it is suppoed to work. The Robohelp "Help" is silent on the matter.
Sorry Peter, I should have said WebHelp Pro, where that option is not available.
The project was originally created as WebHelp and then switched to Web Help Pro. So I assume then that there is no way to alter these window settings retrospectively, and to remove the Glossary button requires a work-around like the one I described. With over 400 topics, creating new windows for all of them is not a practical option.
You select a default window when you generate the help. You make it sound like you have to create 400 windows or attach the window to each topic.
All you need to do is, as Colum said, set WebHelp Pro to be the default, create a new window and select that when you generate.
See www.grainge.org for RoboHelp and Authoring tips
Nope, doesn't work. The Glossary button keeps coming back even though it is not selected in the default window. And yes, WebHelp Pro is the default layout.
Sorry, just read your suggestion again and I now realise you chaps are saying I need to create a NEW new window since the OLD new window was created before the switch to WebHelp Pro as the default layout. I will try that.
I set WebHelp Pro as the default layout, created a new default window with the Glossary button NOT selected, then generated WebHelp Pro, making sure that the new default window was selected in the "Generate" settings.
Result: The Glossary button is still there. It seems to be unkillable.
I have to conclude then, in the absence of proof to the contrary that in RH9 WebHelp Pro there is no way to exclude the Glossary button from the toolbar.
Hi. I think I found the problem. There are limitations on what you can see when you view the project locally from "View Results". You might have missed this dialog box.
If so, the local viewing is not accurate and does indeed show the Glossary button. But, it should be gone once you actually publish and view it from the RoboHelp server.
I have tested this today and found that it works correctly for me. You probably did, but just in case, did you "untick" the Glossary item from the Buttons properties when you created the Custom Window?
Here is a screenshot of what I mean.
Hopefully this will work for you
Adobe Certified RoboHelp and Captivate Instructor
Thanks, John. I’ve not been as lucky as you on this one. Although I have both the Glossary and Index buttons “unticked” in the Window properties, they keep appearing in the published WebHelp Pro output on RoboHelp Server. Oddly though, I have defined custom buttons for the window toolbar and they display as intended. So according to the RoboHelp toolbar, I can giveth but I cannot taketh away.
Following is the ppf file, which may or may not be useful for troubleshooting because I notice it does not refer to the custom buttons:
Now I'm getting paranoid
I wonder if it could be some "caching" situation where the server is not delivering the freshest content?
You might verify the publishing date is current in the Projects pane of the Web Admin app. Perhaps "reload".
Another stab in the dark would be to create a new test "Area" and publish the project using "Republish All" option to narrow down any caching issues.
I know I’m looking at the latest build because if I make a content change and publish, it is there.
But I find that selecting a different default Window when generating appears to have no effect in the output. What could be overriding that selection?
I notice also in the skin editor that there is no option to exclude Glossary, Index or Table of contents buttons from the toolbar; the “minus sign” is dimmed for these selections and only becomes active when I select one of my custom buttons. Is that what everybody sees, or are you able to remove these buttons from the list in the skin editor?
You never could remove them in the skin editor so what you are seeing is normal. It is the window that determines whether or not you get a glossary button, at least, it should be.
Beyond that John is your person but right now he should be tucked up in bed. I am assuming you have selected the correct window in the output dialog.
See www.grainge.org for RoboHelp and Authoring tips
Wading into some unfamilair terrirory here. Bear with me.
I recall when this whole RoboHelp Server thing first appeared (begin creaky old man's voice here) Why, sonny, back in that day it was called RoboHelp Enterprise (end creaky voice) RoboHelp Enterprise was the only way you could merge projects. Okay, okay, I hear you asking how this applies?
Well, you defined more than one project and published them all to the server. The server handled merging. I'm assuming this holds true today.
When the server handles merging, you may nominate one project to be the master project. And if memory serves, the skin applied to the master project determined how things looked for the whole merge. This meant that if the master had specific features and the others didn't, the others inherited the attributes.
So the question here is to ask if you are using the Merge and have defined a Master project? If so, try nominating a different project as the master? Or possibly choose a different project temporarily then change back? (Sometimes just toggling a change like that will re-write what is needed)
Anyhoo... Hope something there either helps directly or manages to spark a thought that eventually will.
Helpful and Handy Links
Further info on this issue, which is still unresolved.
When I use the FIle > View output from server command, the displayed window is exactly as it should be.
It is only when I view the output using the link that the network administrators created, which is a one-word "address" for ease of use on our intranet.
Apparently there is something wrong with the redirection or something.
I found this post by Colim
There is a design flaw in WebHelp Pro where the original project name becomes embedded in WebHelp Pro.SSL at project creation, and cannot be changed except via Notepad if the project name subsequently changes.
Additionally, our redirection on the server was pointing to a specific page rather than Projectname.HTM which apparently is the correct URL for WebHelp Pro.
The combination of these two issues resulted in the inconsistent results I reported.
Thank you everybody.