RH2019 classic baggage reference file issue

Where I am having a big problem with following you is that you are referring to baggage files doing things your way. If you look at my topic on merging CHMs you will not see any mention of baggage files. I have been reading this as your merge is set up by using the different CHMs as baggage files. Do you in fact mean that each project has baggage files for other reasons and that is where your problem is kicking in? Not sure what the answer is there without giving it some more thought but see my last answer below.

If you create links the way I describe and generate all the CHMs to one folder, the merge should work.

My final product must be a CHM file. I must suppose I can choose the output format of the subprojects 

No no no. In a merge all the outputs must be the same type.

Is there a quick way to merge all existing subprojects in to one project?

No, you are going to have to import all the topics into the parent.

I can't tell you why we work with a merged chm project. The only reason I would think of is that in the past we had several persons working on the same project. Not anymore.

If you cannot give a good reason for still working with a merge setup, I would spend the time getting everything into one project and avoiding all this heartache.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

Peter, I'm not aware about using own methods.

I maintain existing sub chm's with baggage files and they are used in a merged, yearly created new project via TOC (and double click to refresh to the sub chm from the target dir)

bagage files are not especially already up to date in the sub chm's (normal, i'm working down a list)

if you compile the sub project, RH overwrites existing chm (already compiled) in my target directory with the versions in the bagagefiles from the subproject and adds chm's if they are not present yet in the target dir. Drops also a copy of the bagage chm in the sub project folder. At least that is what I think happens.

I suppose I have to reimport the bagagefiles, pointing to my actual output directory (where all chm's reside once compiled), for every subproject.

Just wondering if I can:

know which baggage files are really used in links

Sometimes I have 10 to 15 bagagefiles to 're' import. Is there a way to to this in batch? Now I have to point at every bagagefile, import the chm from the target directory, and repeat this until all bagagefiles are 'refreshed'.

I found ctrl F. I didn't see any absolute path to bagage chm's. they are referred just by their name and '::'

About merged chm projects: My final product must be a CHM file. I must suppose I can choose the output format of the subprojects (now also chm).  Which one would be ideal?

Is there a quick way to merge all existing subprojects in to one project?

I can't tell you why we work with a merged chm project. The only reason I would think of is that in the past we had several persons working on the same project. Not anymore.

thanks for the help!

I appreciate it!

best regards

Olivier

When you refer to an external chm, the absolute path is stored. 

From what I can understand you are not truly merging the CHMs, it seems more like you have devised your own method. If you set up the merge as I describe the link should start with the name of the CHM you are linking to. It's years since I have looked at this as CHMs are now so old. I would need to set up a merge again which I can't do for a few days.

Is there a way to search for a string in my project files

CTRL F brings up a seach window that has various options as to where it searches.

Is there a way to tell RH Classic to NOT use a local copy of a external CHM (loose the bagagge file principle)

I simply generated all the CHMs to the same external folder. If I recall correctly RoboHelp still puts a copy in the project that you just ignore. I am a bit rusty on all this but I'm pretty sure I would have covered this on my site.

Is this nightmare been solved in newer versions?

I think it has been improved.

If working with a final chm is still needed, in which format would you compile the subprojects, with the knowlegde that they are now also chm's?

Not following you here. You say "a final chm". In a merge there are multiple CHMs. 

IS a 'big' main CHM a good idea (no merged chm's anymore), what about possible performance issues?

I am going to turn that around. Why did you choose to work with multiple CHMs in the first place? Do those reasons still apply? If not, then you could consider changing. Performance will depend on how many topics in total and the content.

Which are the pro's and contra's for working with a merged chm project against one 'big' chm file?

I notice you say "a merged CHM project" - singular. There are many projects and many CHMs but they work as one. Again that makes me wonder about whether you really are merging in the prescribed way. Either way you having to post all these questions about making a merge work surely answers this question.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

Hello Peter,

thank you for your prompt reply.

I do exactly what you write.

When you refer to an external chm, the absolute path is stored. Of course if you migrate to a newer version, that path should be changed also and there lay one of my problems. I have to screen all topics, look for external references and change them to my upper target directory.

Is there a way to search for a string in my project files, so I can locate all references to baggage files? Either in RH or in windows. what is the name of the file in windows where those links are residing and is it ok to change them with a texteditor and a macro?

In fact I already have to change systematically at every project upgrade the target directory. In my old times this was called the make file. In which file are the target parameters stored?

Is there a way to tell RH Classic to NOT use a local copy of a external CHM (loose the bagagge file principle)

Is this nightmare been solved in newer versions?

If working with a final chm is still needed, in which format would you compile the subprojects, with the knowlegde that they are now also chm's?

IS a 'big' main CHM a good idea (no merged chm's anymore), what about possible performance issues?

Which are the pro's and contra's for working with a merged chm project against one 'big' chm file?

best regards,

Olivier

I have change "luggage" to "baggage" to use the correct term.

Effectively you want a merged CHM setup and in Classic that always was a bit of a nightmare making it work after updating a specific project.

I have described how I got it working in a test setup at Merged CHM Help (grainge.org)

Are CHMs are requirement that you cannot ditch? Merging other forms of help is very much easier.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information