WebHelp ActiveX option not visible to users

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!

In Response To Captiv8r · Aug 06, 2010

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.

In Response To jenniab2 · Aug 06, 2010

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

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!

In Response To Captiv8r · Aug 06, 2010

Any tips on how to post screenshots? Can't see how to post a PDF, and the jpg looks unreadable.

In Response To jenniab2 · Aug 06, 2010

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

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!

In Response To Captiv8r · Aug 06, 2010

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

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!

In Response To Captiv8r · Aug 06, 2010

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.

In Response To jenniab2 · Aug 06, 2010

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.

Click here to view

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:

Click here to view

Cheers... Rick

Helpful and Handy Links

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!

In Response To Captiv8r · Aug 06, 2010

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...

In Response To jenniab2 · Aug 06, 2010

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.

In Response To Jeff_Coatsworth · Aug 06, 2010

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

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!

In Response To Jeff_Coatsworth · Aug 06, 2010

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.

In Response To jenniab2 · Aug 06, 2010

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.

In Response To jenniab2 · Aug 06, 2010

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

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!