Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
CHMs are not my strong suit but a few points until those who know more come online.
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.
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Cheers... Rick
Copy link to clipboard
Copied
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.
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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 )
Copy link to clipboard
Copied
I'm equally as surprised that you report this way of "merging" would work for you. Because it's certainly unconventional!