RH Search not working in files with all-cap filenames

[CletusQMaggot]

Hi all,

This one has me stumped.

Some of the files in our RH projects are in all upper-case.  In these all-cap files, the RH search isn't working, even if I copy'n'paste the term from the content into the Find box.  (It DOES work if I search the source, but just searching the page doesn't.)

If I duplicate the file and the dupe is in lower-case, search works like you'd expect.

In the example below, the same term is in both of these files. But you can only get a search result on the acheck file -- the ACTRENUM one returns zilch.

My *guess* is the problem is more with the .HTML extension than the filename itself, but a guess is all it is.

Has anyone seen this before? And maybe encountered a way to fix it without duplicating possibly dozens of files? (This is RH 2015 btw)

Thanks!

Christian

[Captiv8r]

Hi there

First I've seen of this. Wondering what your output type is? If it's WebHelp, you may be in luck as there should be an option to convert all your files to lower case.

Cheers... Rick

[Jeff_Coatsworth]

@Cletus - I'm unsure where the problem is occurring - in the RH project itself or in the generated output files from that project?

[CletusQMaggot]

This is inside the project itself. Searching in Robohelp won't find results in these files.

Once it's published, text search in the browser works as anticipated.

Thanks!

[Jeff_Coatsworth]

Is it happening with RH topics you create "fresh"? (I ask because I suspect those .HTML topics have come from someplace else)

[CletusQMaggot]

Yep.  Just created one with the .HTML extension.  No luck on the search. 

[Jeff_Coatsworth]

Aren't RH topic filenames created as .htm files as a default?

[CletusQMaggot]

They are.  But if I force it to use .HTML, the search breaks.

I don't know how we got so many .HTML files in here. I did a count of them and it's not dozens, it's more like 500, almost all of them predate me at this company.

But I'm suspecting sloppy coding on Adobe's part. When's the last time the capitalization on a file extension caused a problem for a search engine? 1994?

[Jeff_Coatsworth]

Ok, so to narrow it down - create ".htm" type files in both cases & see if the Find breaks on them; if so, then file a bug report; if not, then the issue must lie in the ".html" extension - report it, but stop forcing that extension.

[CletusQMaggot]

Okay, FTR - all-cap .HTM has the same problem. Lower-case .html works fine.

And don't worry, no one is forcing any extensions But these 500 files already have them -- they must have been imported from some other tool in the dim and distant past.

I'll log a bug. Thanks!

[Captiv8r]

Hello again

Apologies for misunderstanding that you were talking source and not output.

How exactly are you performing the search?  (I know you said you are using RoboHelp 2015, but what steps are you taking inside the application?)

Cheers... Rick

[CletusQMaggot]

I'm basically just opening the topic and searching with the Find and Replace pod.  No hits (unless I search in the source code) if the file extension is either HTM or HTML.

If I search across the entire project, it doesn't find the term in any of the topics with the upper-case extension.

Pretty basic search stuff

[Captiv8r]

I just tested this and see similar results.

I'd have to say it's a bug.

I was able to coax RoboHelp to find my topic by configuring the "files of type" to be "all files" as well as enabling the "Find in source code" option. Perhaps try that?

Cheers... Rick

[CletusQMaggot]

I hadn't tried changing the file types to search, but the source code check box does find it even with the default htm option selected.

I'm glad someone outside this building can see it. Was starting to think there was something in the water

[Peter Grainge]

There are many tools out there that will change HTML to HTM in bulk but of course that will lead to broken links if you have created them to HTML files. You will also be able to change the case in the process. In RoboHelp you should then be able to change the links.

That said I just opened a test project and changed first_topic.htm to FIRST_TOPIC.HTML. Then I went to the Find and Replace Pod and search for something only in that topic. It found the file. I also played around with telling RoboHelp not to allow spaces in file names and creating a file, then turning that setting back on. Still it found the file.

Is that where your search is failing? Also try importing a couple of those topics into a test project to see if it still fails.

Let's not call it sloppy coding until we know the cause is capitalisation. That is not making any difference in what I have tested.

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[Peter Grainge]

Another thought, have you tried deleting the CPD file and reopening the project? Does it work then?

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[CletusQMaggot]

I don't know what to tell you.  It fails reliably for me with HTM or HTML extensions.  It continues to fail if I import a file with one of those extensions. It fails the same way in every project I've tested. Deleting the CPD file changes nothing.

I agree it could be something other than sloppy coding -- although I am confident enough with my own skills at doing a text search to not really consider user error (Plus, someone else here found this issue and passed it to me...)

The only options I can see are: a) duplicating and replacing 500 or so files, b) ignoring it completely and training everyone to search in the source code, or c) changing the file extensions on the disk AND in the Robohelp system files, like hhc and wherever else the project files are listed.

Fortunately, our intern just finished her term and is looking for summer work.  Mwa-hahahaha

[Peter Grainge]

1 - Did you try importing two topics into a new project as suggested?

2 - Do you have Update 4 applied?

3 - What O/S are you using?

4 - Where is the project? Local or network?

5 - How long are the paths from the root of the drive?

6 - If all else fails, could you share the project offline?

[CletusQMaggot]

1 - Yes. No difference.

2 - According the Updates option from the help menu, I'm up-to-date

3 - Windows 10

4 - Local (we share them via source control but we work locally)

5 - The path to the project where we discovered this is: C:\_robolocal\Beverage\Beverage KB\beverage_kb.xpj

6 - Probably. I think I could zip the whole thing up and put it on Dropbox long enough to share it

Thanks

[Captiv8r]

Oddly, with the .HTM extension, the search seems to actually find the file but refuses to list it in the pod.

Cheers... Rick

[CletusQMaggot]

Weird. It's like it's Inceptioning itself.

[Peter Grainge]

See the Contact page on my site. Dropbox is OK but wetransfer.com might be

easier.

If you use Dropbox, see the Contact page for the email address to use. Do

make sure the copy is not under source control.

Suggest a couple of search terms that fail for you.

[Peter Grainge]

So is the issue the term not being found or it not being in the list?

[CletusQMaggot]

Not finding the search term at all is the main problem. This thing that Rick found with it actually finding them in multi-topic searches and refusing to list them is one I hadn't noticed before, but that could be a huge problem with global search and replace tasks.

I hope solving one solves both.

[Peter Grainge]

Sorry if some of my replies seem to ignore earlier posts, it's the timing of when I get the emailed advice.

Since Rick posted, I too have now found the issue is capitalisation combined with Find in Source Code is the issue.

Post it as a bug. Please follow this link to report bugs and request features. The more people who do so, the higher it gets prioritised.

https://tracker.adobe.com

Post the link to your bug back here and people can vote to support it.

Finally, if you want to still send the project, I'll see if I can fix that relatively easily with various tools I have. It might be better to use wetransfer.com to ensure there are no ties to source control.

I will not be able to look until tomorrow at best and obviously you will have to suspend work until I have fixed it. Maybe send it when you close Friday?

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge