cannot find any search results in CHM - strange behaviour

[Krischu]

I have a central CHM of a merged Robohelp HTML Help project in which I cannot find any search hits.

In a different one built at another date I can find results. (this is independent on the subprojects chms being there or not. Alone that central CHM exposes the strange behaviour)

The funny thing: a colleague cannot find search results in the same CHM (in which I can find results). OTOH, when I try the CHM where he can find results

I don't find any. When I try the same on another machine, same picture with me.

How can this be?

--

Christoph

[Krischu]

I can add a few datapoints:

I have two trees in which I can compile the CHMs, both are SVN-based.

I generated a new CHM and put it on a network drive for being able to share  resp. test it from different systems (Windows7 Windows 10)

The stress doesn't ly on network here. I believe it is noc a network issue. The effect also occurs when the files are copied to the local machine.

I was able to invohe the CHM (double click) on the icon and could open a search giving me 52 resuts.
Doing the same from another Windows machine , I can start a search and get 197 results . Same CHM

Now I went to a third machine, Windows 10 (VM under MacOS Parallels), in same network , click on the chm, no search results found

So what is going on here?

From my understanding the search is done via indexing, an index is generated.

Does it have to be the named index of the project (in the SSL configuration view) or does it have to be the "default index"?

I believe it must have to do something with the index.

Could it be any cache effects? Are CHMs chached somewhere on the respective OS that invoke the CHM. I'm clueless for the moment.

--

Christoph

[Peter Grainge]

CHMs are not my strong suit but a few points until those who know more come online.

1. CHMs are not supposed to be run from a network, unless you apply certain registry changes. See CHM Files Not Working on Network
2. The search terms are stored in a number of files based on the topics in the project. The index is a quite separate thing.and does not affect the search.
3. Which index you select affects what is seen in the Index tab of the output and does not affect the search.

On my site there are pages on Merged Help with a section on CHMs. Maybe something there will help

I can't think why you would get different results if you are looking at exactly the same files and they are out of version control. Hopefully someone with more CHM knowledge can help you.

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[Krischu]

Further investigating the behaviour of the CHM I found something really puzzling:

The machine on which I compile the CHMs has a directory tree

C:\Help\Projects\etc etc      (working copy)

On the machine I'm testing, there is the same tree

C:\Help\Projects\etc etc    (somewhat older version)

(more or less by accident)

Now when I copied the new CHMs to the test machine I was wondering why I got old images in the CHM (the names were the same but they have been updated by new contents). Huh? Clicking the page on the development machine give the new images, clicking on the test machines I see the old ones?

Now when I right click on one of the images (that should have new contents but appear to have old contents) I'm getting:

Address: mk: @MSITStore:C:\Help\Projects\etc etc

since this path appear to be there on my target machine (test machine), the old image contents seems to be refered.

Why is that referred outside the CHM at all?

I would expect the CHMs to be self contained without any reference to the outside.

BTW, do the Merge CHM-Files specified in the MERGE FILES section of the .hhp file have to be specified with absolute paths?
We did it recently as it seemed these paths were modified by some magic all the time. In the .XPJ merge section all files are without any prefix.

When doing a next test, I deleted the .cpd and started over the create the merged CHM newly. I now get the correct icons contents, but the search function doesn't reveal any results.

Really puzzling.

--

Christoph

[Peter Grainge]

See Item 6 in Snippets CHMs. I am wondering if it is something to do with registration of DLLs. I really don't know.

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[Captiv8r]

You might want to visit the link below and download and install MJ's Diagnostics on the PC where search isn't working. I believe when this happens it's because one of the DLLs used isn't working or needs updating.

Click here to view

Cheers... Rick

[Krischu]

Captiv8r  schrieb

You might want to visit the link below and download and install MJ's Diagnostics on the PC where search isn't working. I believe when this happens it's because one of the DLLs used isn't working or needs updating.

Click here to view

Cheers... Rick

But can it be that I have to tell my customer to run this tool on his computer to view my CHM? This can't it be, really?

I ran this tool on the producing machine (a german Windows 7 VM).  The search is functioning there.

Interestingly the tool listed DLLs to be registered. I clicked on register. It did something silently but after that the list of DLLs was still shown.

I'd expect them to disappear once being registered.

--

Christoph

[Peter Grainge]

I'll leave Rick to reply fully but it will be a few hours before he comes online. No you don't ask the customer to run the diagnostics. It's up to your developers to register the DLL properly when the help is installed.

Also, just to reiterate, CHMs should be on a local drive unless the registry of each user is amended.

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[Krischu]

I copied them over from the network drive to a local directory to be 100% sure I've eliminated this possible cause (I had the appripriate registry settings in HKLM\Software\Microsoft\HTMLHelp and Wow6432Node resp.

I also ran this script on the target machine (where things don't work as expected):

regsvr32 /s C:\Windows\SysWow64\hhctrl.ocx
regsvr32 /s c:\Windows\SysWow64\itss.dll
regsvr32 /s c:\Windows\SysWow64\itircl.dll
regsvr32 /s C:\Windows\System32\hhctrl.ocx
regsvr32 /s c:\Windows\System32.itss.dll
regsvr32 /s c:\Windows\System32.itircl.dll

to no avail.

There are also some DLLs from Microsoft Help Workshop to register when I invoke the MJ tool on the production machine but I guess these won't be necessary on the target machine, are they?

The funny thing is that the search just doesn't work in the merged CHM (which has the sub CHMs a baggage files). Searching in the Sub-CHMs works.

--

Christoph

[Captiv8r]

Whoa there - Stop the presses!

You say that where things aren't working, you have a CHM file that you fashioned into a massively larger CHM file by adding the other CHM files as baggage?

If that's the case, I'd be surprised if any machine would be able to find the topics of any of the baggage CHM files. That's not any "proper" way to perform a merge with CHM files. Normally you simply add references to the TOC for the sub CHM files, then deliver all the CHM files separately.

I'm thinking you may want to reconsider your approach on this.

Cheers... Rick

[Peter Grainge]

In my first reply I did suggest looking at the pages about merging on my site. That sets out the structure.

See Merged CHM Help

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[Krischu]

Rick,

I'm surprised about your answer. My colleagues say, that the search worked in earlier versions of the project and from some point in time it stopped working.

I will have a look again at the pages on Peters site, as he suggested.

I'm puzzled at the moment.

--

Christoph

P.S. I found in Peters` pages that something is with absolute path names in the .hhp-File causing trouble. Making these to relative filenames with a .\ in fron of the name seems to cure the problem. I mentioned this being the case with me here (absolute pathnames) earlier already. (I must still say "seems", I tested the result on three different computers positively now and I'm still waiting for the OK from my colleague that he is seeing the same good result )

[Captiv8r]

I'm equally as surprised that you report this way of "merging" would work for you. Because it's certainly unconventional!