Adobe Community : All Content - All Communities

Search not working in Windows 7, works on XP

forums_noreply@adobe.com — Tue, 17 Jun 2014 15:00:53 GMT

Hi folks,

We had quite a time getting RoboHelp for Word to work on our new Windows 7 machines. The highest supported combination (of RoboHelp version and Word version) that we were aware of from the postings on this site did not work. Long story.

Anyway, we ended up reinstalling RoboHelp 7 and Word 2007. We have Word 2010 on our machines for other things, but we use 2007 exclusively for RoboHelp. We still save our files as .docs instead of .docxs. (This was a decision made long ago and there was a reason for it, I think, but I don't know it now. :-P I'm just mentioning it on the off chance that it's relevant.)

We thought all our problems were over - the help seemed to be compiling fine - BUT: the Search tab does not work on Windows 7 machines. Comes up completely blank.

The same help file, including the Search tab, will work fine on XP machines.

Any advice?

Thanks in advance - Sandy

is it possible to create a custom 404 page for .chm help?

forums_noreply@adobe.com — Thu, 03 Apr 2014 15:09:54 GMT

Hello,

I have a custom 404 "file not found" page that I use in web-based help outputs. I would like to be able to use it in compiled .chm help.

Does anyone have experience with this? Or is it not possible?

The scenario is that we have several related .chm files. All clients will have the help file for the base product but may or may not have the other help files, since those products require special licensing. We'd like to link the .chms. In old WinHelp days this would be easily done through the .cnt file, and clients just wouldn't see the external links in the .cnt if they didn't have the help system. But since I can't link the .chm help systems in this scenario without possibly having broken links, I'd like the broken link page to provide an explanation of why the user doesn't see help. If anyone has handled a similar situation, I'd be interested in your ideas.

Thanks in advance.

"RoboHelp has stopped working" error

forums_noreply@adobe.com — Tue, 08 Apr 2014 21:48:41 GMT

Hi,

I had replied to pgcalc's post with this but since it is a different error I am getting, decided to start a new thread.

I have:

-new Windows 7 machine

-Word 2010

-RoboHelp for Word 10

But when I try to open an .hpj - obviously, these were created in older versions of RoboHelp - I have no idea which version, originally, but the last work on the project was done in RoboHelp 7 or 8 - I get the message "RoboHelp has stopped working."

Here's what I have done so far:

I noticed that the RoboHelp templates were not installed in the default Word templates folder like they usually are. So I copied all the templates from C:\Program Files (x86)\Adobe\Adobe RoboHelp 10\RoboHELP\WordTemp\en_US\Word11 to C:\Users\[yours truly]\AppData\Roaming\Microsoft\Templates. Still no luck.

Any advice?

Thank you,

Sandy

Message was edited by: sdryer

Any problems running Windows 7-created help output on Windows XP machines?

forums_noreply@adobe.com — Wed, 26 Mar 2014 19:40:13 GMT

Hi,

I feel a bit silly even asking this, but I'm not a coder and don't have the technical knowledge to know for sure that it's a silly question.

Background: We are upgrading to Windows 7 from XP in the near future. We will be using RoboHelp 10 and Word 2010 - at least that's the plan ...

For our department's major product, since it's big and has been around a long time, we are still stuck using RoboHelp for Word to generate WinHelp. We then use the RHelp for Word source to generate WebHelp, since some modules of the product require WinHelp, some require HTML pages, and much of the source material is needed in both outputs. And yes, I did read someone's post likening this process to drinking coffee while running a sprint - believe me, if I had any choice about this I wouldn't be doing it. If RoboHelp has added the capability to generate WinHelp from RoboHelp HTML, let me know .

Anyway, because of previous weird experiences after upgrades, I am being asked to find out: Has anyone used RoboHelp for Word to generate help output - .hlp or .chm or HTML pages - on a Windows 7 machine and tested it on a Windows XP machine? If so, were any problems observed?

Assuming we can still creak along with RoboHelp 10 to generate the same antiquated output ... which we can, right?? ... my gut tells me that a file is a file and I can't see why an .hlp file or web-based help files that run on Windows 7 wouldn't run on XP. But again, I don't have the technical knowledge to say this for certain.

Any advice appreciated. Thank you - Sandy

Message was edited by: sdryer

indents too large in bulleted/numbered lists, WebHelp output

forums_noreply@adobe.com — Tue, 12 Apr 2011 21:49:53 GMT

Hello again,

As explained many times previously on this forum, we use RoboHelp for Word to generate both WinHelp and WebHelp output.

Usually I have troubles with WinHelp. This time, the WebHelp output is acting up. Bulleted and numbered lists look fine in compiled WinHelp, but in WebHelp output the space between the bullet or number and the text is much larger than it was defined to be. It looks bad and is pretty pervasive, so I can't ignore it.

To complicate matters further, sometimes the indents are OK in the WebHelp, and it seems to be the same Word style applied in both instances.

I saw several references to bullets and numbering problems on the forum, but none that described this exact problem in this particular product, and usually it seemed the solution was to change a Word option. This wouldn't seem to make sense in this case, given that our WinHelp came out OK, but hell, when it comes to RoboHelp I'll try anything once. I experimented with the "Don't use hanging indent as tab stop" setting as described in http://forums.adobe.com/thread/791539?tstart=0, but so far no luck.

We are running RoboHelp 8.2, with Office '07, on Windows XP. As always, any advice is very much appreciated. - Sandy

P.S. This isn't a RoboHelp issue - but anyone know why it could be that when I type "list" or "bullet" or "number" or any form thereof, into the Search field on the Forums, it says there are no entries, when obviously I found some? (I wasn't using the quotes in my search.)

replacement ImageAPI.dll causing new problems

forums_noreply@adobe.com — Wed, 21 Jul 2010 16:49:54 GMT

I was trying to help JonC (http://forums.adobe.com/message/2984518#2984518), thinking that I was using the new ImageAPI.dll successfully, but it turns out that I haven't been.

I have to generate WebHelp and WinHelp from RoboHelp for Word. In the project that I just finished, before I had the new version of the ImageAPI.dll, when I was getting the weird truncated topic ID problem (http://forums.adobe.com/message/2939947#2939947) ) I was always able to save the .shgs ONCE successfully. If I opened them up again, the links would break.

So, if I was careful not to reopen the .shgs once I'd saved, my WinHelp was actually turning out OK. But when I then went to generate WebHelp (from the same source files), the links in the .shgs would break (I'm assuming this happened when the .shgs were opened, behind the scenes, for whatever conversion process they go through).

So the new ImageAPI.dll fixed my hotspot graphics in the WebHelp so they worked just fine, and I was able to get my project out the door (thanks again, Peter). But because I had always been able to save the .shgs once successfully, and I'd already turned in my WinHelp files, I never got to see what would happen if you inserted a new .shg that had been created with the new ImageAPI.dll and compiled it in WinHelp.

Now, this morning, I'm seeing it (as we start a new project), and it looks like we are getting the same problem as JonC - if you put hotspots in, images disappear.

Seems like the new ImageAPI.dll is buggy. Anyone else experiencing this?- Sandy

TOC not working in WebHelp - unwanted prefix appended

forums_noreply@adobe.com — Wed, 17 Nov 2010 17:35:29 GMT

Hi,

We are using RoboHelp for Word (8.2) to generate a multi-.hlp WinHelp project and then a WebHelp project from the same source. We have a master .cnt file that includes the .cnt files from all the .hlp files.

The WinHelp is working OK (except for the .shg problem that I have posted about many times before, but we've given up on that for the present).

Our current problem is that when we generate the WebHelp project, the TOC does not work except for the initial file (the one that the .hpj is named after and that appears when you open the project).

If you click on any other topic in the TOC, it doesn't work, although if you open the topic from the project's index or search tab, it works.

I can see what the problem is, but I don't know how to fix it. Here's a picture. I apologize for the fuzziness, but I think you can see in the circled area that the TOC link is looking for a file called program_programming_flowchart.htm. The actual name of the file is programming_flowchart.htm. Apparently RoboHelp is inserting a prefix that includes the name of the included .cnt file (in this case, program.cnt).

I found a place in RoboHelp (under Tools>> Options) that looks like it would control something like this, but the check box is not checked. I looked both in the main WebHelp project and in the original WinHelp sub-projects and it was not checked anywhere. Here it is:

Does anyone know how to stop this behavior?

Thank you - Sandy

context-sensitive help breaking in RoboHelp 8

forums_noreply@adobe.com — Thu, 01 Jul 2010 14:48:02 GMT

Peter - you're a lifesaver and I hope you're out there today . . . or somebody's out there who can help . . .

I shouldn't have said that in my last post about something being the "wackiest" thing I'd ever seen in RoboHelp. Now we have a new problem that's much more serious.

We have an aforementioned (in previous post) enormous RoboHelp 5 project, converted to RoboHelp 8 after much anguish, replacing hundreds of WYSIWYG graphics with true code etc. Map IDs were *not* touched.

Now the context-sensitive help for our VB app is not working, even though the map IDs are still in place on both ends (dev and docs) and all the relevant .hh files were included in my compile. Some topics (within the same help file) appear when called from the app, some don't.

A developer had a theory that in one case the topic ID was assigned (on their end) during design time, the other during run time. He's testing it now.

If it doesn't work, I have no idea where to begin. Is anyone aware of any changes in RoboHelp 8 that would affect the way the .hlp links to VB?

Thank you! - Sandy

topic IDs disappearing from .shgs

forums_noreply@adobe.com — Wed, 30 Jun 2010 22:40:14 GMT

Hello - I posted this earlier as a response to a thread, and I'm not sure it got out to anyone besides the original post-er, so I'm reposting. If this is a duplicate for anybody, my apologies.

I am in RoboHelp 8 (with all applicable service patches), using Word 2007 in compatibility mode, on Windows XP if that matters. We have an enormous, multi-.hlp system that we are required to generate as an .hlp and then as WebHelp. (Don't ask me why :-) ).

My problem is that in this enormous project, out of all our many .shgs, there are about 4 of them that have stopped working. I found the problem when I looked in my Broken Links section of the Explorer pane and saw a bunch of bizarre, one-letter topic IDs. They were all in these 4 .shgs - all the topic IDs that were being called from all the hotspots in these .shgs had simply disappeared and been replaced with single random letters.

I have deleted the .shgs, gone back to the .bmp, and redrawn them more than once. I was able to get them to stay in place for one WinHelp compile, but then when I went to generate the WebHelp output they were all back again.

(I considered giving the topics an alias of that one letter as a workaround, but unfortunately all of the one-letter context strings seem to be called by more than one .shg.)

This is perhaps the wackiest thing I have seen in 10+ years of working with RoboHelp, and that's saying something :-). Has anyone seen this before? Thank you,

Sandy

"access unnamed file" error; search tab not working on Citrix

forums_noreply@adobe.com — Thu, 27 May 2010 17:33:34 GMT

Hi folks,

We have a WebHelp project and a WinHelp version of the same project, generated in RoboHelp 8 and we're having some weird problems with it.

Problem 1: When the WinHelp project is viewed via a Citrix server, the full text search tab comes up blank gray. When the project is run locally it works fine. Anyone had experience with this or have any idea what it would take to solve it?

Problem 2: When you select one particular menu item from the app (others work), it does not launch the help. Instead you get the following error:

Release of product is imminent. Gloom abounds. Has anyone seen this before? Can you help? Thanks.-Sandy