Copy link to clipboard
Copied
Launching our WebHelp from the "Help" link in our browser-based application, users get the help in a new window but they do not get the message about enabling ActiveX that I see when I launch the help locally... which means that they do not get the Search field in the toolbar nor in the Search tab, and the Search tab is an embarrassing (and confusing) list of every possible item that might be searched. It also means they don't see the colors of the skin we created for the toolbar, because the ActiveX toolbar doesn't replace the default WebHelp toolbar.
This WebHelp was created with RoboHelp 7, running in IE 8.
Any ideas how to at least give our customers the option to allow ActiveX?
Copy link to clipboard
Copied
Hi there
You seem to be stating you have a web based application. Is it safe to also assume your WebHelp is also being served from a Web Server?
You only see the Yellow Information Bar (YIB) under specific conditions.
If your WebHelp is being served from a web server all the points above are moot. You only have concerns if you are supplying the WebHelp content to each user's local C drive.
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
Yes, the WebHelp is being served from a web server. Thank you for the explanation about the YIB conditions!
How can we provide a search field for our help users accessing WebHelp from a server? Is there another way to enable ActiveX or is there another way to have the search field appear in WebHelp?
The exhaustive list of potential search terms in the non-ActiveX Search tab that we see is really frumpy, and not user-friendly.
Copy link to clipboard
Copied
Hello again
So can you post some screen captures of each screen you see in the WebHelp generation dialogs?
Double-click the Single Source Layout and you get a dialog. At the bottom of the dialog is a button labeled Next >. These are options you pick and choose for your Single Source Layout recipe. Each of those options governs what you get in the resulting WebHelp. I'm thinking you may have a few options that are causing this. Only by seeing what you are seeing will I be able to confirm or deny and offer guidance.
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
Any tips on how to post screenshots? Can't see how to post a PDF, and the jpg looks unreadable.
Copy link to clipboard
Copied
You might be better off just sending these to me via E-mail.
Please send to rstone75 (at) kc (dot) rr (dot) com.
I did notice they were all wacky.
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
Hello again
Okay, I'm admittedly a bit puzzled at this point. I did receive your PDF. I somewhat expected to see that you had Section 508 enabled on the first screen or you had enabled "Pure HTML" on the third screen. But these look fine.
This can only mean that the browser you are using has probably had the ability for JavaScript to be disabled. Here's why I say this.
When WebHelp launches, it sets some things in motion. There are scripts that sniff the browser in use and determine the capabilities. Then depending on what it finds, the WebHelp may degrade to present in various flavors. Your mention of seeing the Search appear in the manner you are describing seems to indicate the WebHelp is dropping presentation down to PureHTML output.
Question here. Does this happen for ANY PC in your organization? If so, perhaps your IT staff has specifically configured their browsers so they aren't capable of DHTML (DHTML is Dynamic HTML - meaning HTML pages that use JavaScript to achieve dynamic effects)
As I'm a forum moderator, I'll happily attach the PDF here for others to review if you say it's okay to do so.
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
I believe this happens for anyone launching the help from the application (therefore from the web server), internal and external.
Is ActiveX the *only* way to get a search field instead of the messy Search tab list in WebHelp? ...You mention DHTML, which I know is not disabled because we use it for our own viewer.
Copy link to clipboard
Copied
Hello again
In this particular case I do believe ActiveX is a bit of a misnomer. ActiveX normally refers to a specific control. An applet in the browser. It's specific to Microsoft Internet Explorer. You can read more about ActiveX at the link below.
What happens is that Microsoft Internet Explorer posts the YIB with a rather generic ActiveX warning because it is seeing the JavaScript. I dunno, maybe IE uses an ActiveX control to interpret the JavaScript. That's far beyond my capabilities to explain.
So to answer your question, yes your users will need a JavaScript enabled browser in order to see your WebHelp skin in all its glory.
Assuming your IT peeps have allowed you access to these settings, you might investigate changing some options for IE as described in the link below:
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
Thanks for the suggestions, Rick. Changing those settings in the browser (IE) doesn't get us the Search field in the help on the server.
Not being able to search in WebHelp viewed from a server is a major weakness in the accessibility of our documentation -- and the Search tab alphanumerical "dictionary" of searchable terms is a weak alternative.
The only solution we’ve found is enabling ActiveX control, but we only see that option when help is local. What we’re really looking for is any recommendations for how to get the Search field to display when help is being served from a web server.
I don't know who developed the WebHelp framework (not Adobe, not Microsoft?), but I sure wish we had something else.
I'll cross my fingers that when we generate from RH8 this issue will magically be resolved... but it's unlikely, as WebHelp itself hasn't changed. Such a pity, because we can't run CHM from a server either...
Copy link to clipboard
Copied
Have you tried using another browser to see what happens? I could see your SSL screenshots when viewing your post via e-mail & I'm curious about the section called "Navigation Pane Preferred Format" - I don't get that when I'm generating. I only see a DHTML > Pure HTML/Pure HTML radio button choice. Are you using the WebHelp SSL or WebHelp Pro versions? I would try just using the "regular" SSL version & then manually copy the \!SSL!\Webhelp\ folder contents to the web server & see if that makes any difference.
BTW - you can run CHM's from a server - it just requires a bit of hacking. There's some info posted on the forums about how to do it.
Copy link to clipboard
Copied
Hi Jeff
I believe this is RoboHelp 8 in use. That's why the dialog appears differently.
Click image below for larger view...
You are technically correct regarding the CHM use, but seriously misleading. The "server" mentioned here is a Web Server not a network server. CHM format may be viewed (with registry tweaking to relax security and open the systems a bit) only from a network server.
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
Doesn't work in other browsers either.
We generate WebHelp (not WebHelpPro), and the generated files are built with the application and installed on the server with the application. The dialogs I posted are from RoboHelp 7. I haven't converted this project to RH8 yet (but I'm hoping for a miracle when I do!). You might see something different for that SSL screen based on what you have selected in the previous screen... maybe 508 compliance?
We can't ask our customers to do any hacking on their systems to see the help for our applications -- they all have security concerns about their systems as it is.
Copy link to clipboard
Copied
Right - as Rick pointed out it's an RH7 dialog & no, CHM's are not the way to go these days.
Have you tried using one of the sample projects & testing with it? If that works, then it's got to be something to do with the "problem" project.
Copy link to clipboard
Copied
Hello again
So a thought occurs here of a way you might test to see if it's the project or the browser. Simply open a WebHelp that exists on the web generically and see if you are able to see the skin!
Click this link and report back whether what you saw looks like the image below.
(Click the image for larger full sized view)
My thought is that if things appear in your browser exactly as they appear in the image, then it's got something to do with your project. But if it behaves as you are reporting your project is behaving, then it is your browser that is at fault.
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
In case it will help, I recorded a small video...
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
Hello again
Can you possibly share a URL so I might be able to see the help first hand and test from my end? Or is this behind a firewall?
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! |
Copy link to clipboard
Copied
Sorry, no, our product/help is not accessible externally.