How to specify a "remote" file path in the HHP [MAP] section?

[BarryMV]

I need/want to specify a common context sensitive ID map file from several projects but can't figure out or find documentation about how to refer to a file that is NOT in the project directory.  For example, if I have a file called HelpContext.h in ProjectA's directory, under the [MAP] (and possibly the [TEXT POPUPS] section, then the ProjectA.HHP file can contain something like this,

...

[MAP]

#include HelpContext.h

[TEXT POPUPS]

HelpContext.h

And it builds and works fine.  But if HelpContext.h is a file used by several projects, I would like to be able to reference it something like:

[MAP]

#include <a file path to HelpContext.h>

[TEXT POPUPS]

<a file path to HelpContext.h>

All the examples I've stumbled on assume the .h file will be in the project directory.

Thanks.

[kglad]

what adobe app?

[BarryMV]

Oops. RoboHelp 2019 Classic.

[kglad]

in the future, to find the best place to post your message, use the list here, https://community.adobe.com/

p.s. i don't think the adobe website, and forums in particular, are easy to navigate, so don't spend a lot of time searching that forum list. do your best and we'll move the post if it helps you get responses.

<moved from using the community>

[BarryMV]

Oh. Another oops.  Thanks.  I'll wait to see what happens once you move it.

[Peter Grainge]

It's also best to state which version of Classic you are using. I know it is 2019 because of recent threads but others may not.

I haven't used CHMs for over twenty years but I don't think you can do what you want using map ids. Your can create a URL to another topic so perhaps that's the way to go.

I know you are doing a lot of updating. Whilst CHMs have the advantage of being single file, they are otherwise becoming very dated and lacking modern features. Time to consider going the whole hog and going to a modern format?

________________________________________________________

My site www.grainge.org includes many free Authoring and RoboHelp resources that may be of help.

[BarryMV]

Hi, Peter.  I indeed find myself in a peculiar and possibly unique position in having to "modernize" a huge cache of X3 documentation.  Though the documentation aspect of my work is really a small part, I got left holding that particular responsibility, and now that I'm nearing retirement, the powers that be want to "future proof" everything, including the documentation, whatever that means!  I thought that one step in the right direction was to bring the X3 stuff, original developed in the 90s to a more current state.  I landed on 2019 Classic after much flailing and experimentation with the vague notion of being better able to use that version (2019C) as a spring board to ... well ... whatever ultimate direction I decided to go.  In short, a complete conversion to 2019C, using the CHM format, would be a reasonable worst case state in which to leave things, for whomever inherits the responsibility.  THAT SAID, I recognize the waning (waned?) nature of the CHM universe, but being only an occasional dabbler in all things documentation-oriented, it's abundantly UNclear what would be better.  As such, I'm all ears insofar as recommentations go.  I would greatly appreciate any suggestions you might have.
To set the context slightly better, I work on and develop industrial automation system platforms and to some lesser extent, the target industry layers that ride upon it.  The documentation in question is about the platform which is used to develop specific sector product, end user systems.  Given this, the documentation target audience is primarily application developers who refer to the documentation both at the project headquarters as well as when they are installing systems on sight.  The end product installations are on secure systems that may or may not be even partially able to reach the internet, so an external/remote server-based documentation access seems (to me) dubious at best.  Of course, there's more to this story, but perhaps you could take that into consideration when you graciously suggest alternatives to the CHM approach, (wink wink)

[Jeff_Coatsworth]

Frameless HTML5 is the way to go - that's where Adobe is putting its dev efforts and it works fine on internal systems without Internet access. I get around the issue of having to ship thousands of files by creating a self-installing executable and shipping that with our product. 

[BarryMV]

Thanks, Jeff.  It's not clear what HTML5 brings to the table beyond the fact that it's newer.  I don't mean to sound ungrateful, but, in the end, my most basic needs come down to this: 1) a simple means of distributing (and moving) the entire set of documentation which consists of some 50 RH projects, and 2) having the ability from within my main product software to reach into that set and display context sensitive information.  And, by the way, the main product is primarily written in C++.  In any event, thank you for your input!

[Jeff_Coatsworth]

Yup - both of which are quite possible with HTML5 and more "future-proof" then CHMs because the text is all there as HTML. 

[BarryMV]

Good points, Jeff.  I'll check it out.  Thanks again.