search capabilities for mergedhelp

Have you checked out Peter Grainge's site (grainge.org) on merged help?

I'm not sure myself - I don't use it. I think that the idea was to not create such a huge project in one go - splitting topics up into multiple smaller projects and then merging the results in one parent project is supposed to be easier on the system than creating a monster project.

I do something similar to that in one of my help projects - I use FM's "book of books" concept to break up content into modules and then assemble them all in a master book (which then gets sucked into RH for WebHelp creation).

Hi there

I'll try to help.

Firstly, Jeff, sorry, but I have to put on my grumpy hat again. You really do need to consider that not everyone remotely understands Frame. It might be okay to make that assumption if replying in the RoboHelp Frame forum category, but I'm not sure I'd expect it in the AIRHelp category. What is a book within a book? Are Frame books the same as RoboHelp TOC books? Are they simply a means to organize a collection of links to topics as they are in RoboHelp? See my point?

I'll have to leave it to Peter or another to address merging with AIR. I've not done that myself and I'm not sure it's possible to make it work like a merged CHM or WebHelp will.

Karen, I'm a bit confused by your mention of "Inserting a CHM reference in the TOC". Can you expound on that please?

I'm confused because when you create a merged CHM set, that's precisely how you define the child reference. By inserting it into the TOC of its parent. Then at runtime, assuming the files can be found, the end user is none the wiser they are using multiple CHM files. From their standpoint, assuming things are working, they believe they are interacting with a single CHM.

There are a few benefits of merging. One is that you have an ability to break things into smaller chunks. That makes them simpler to manage. Another is control. You are able to better control who sees what. For example, say your company produces a product that exists as ten different modules. The customer may mix and match modules as they wish. So customer A may have modules One, Three and Five while customer B may have modules Three Four and Seven. So your installer could provide help for only the installed products by including only the installed modules.

Hopefully this helps... Grump... errr, Rick

More coffee, Rick = less grumpy? :>)

Just trying to make an analogy for those coming in from the TCS world - I forget that the RH forum hasn't been totally subsumed into the TCS umbrella (yet ;>) ) - FM books are like RH projects in that they collect stuff up in one package.

LOL... indeed I do need coffee!

Okay, first off let's try to clear something up. This post is in the AIRHelp category. But are you trying to produce AIRHelp? If not, why are we talking about CHMs so much? Or was it that I simply got sidetracked in trying to explain how the merged CHM setup works?

You also mention the "Redirect" page. That normally only applies to the Merged WebHelp and FlashHelp outputs and the special way Peter creates things in order to make linking between projects simpler.

So bottom line is that a Redirect is NOT needed when merging CHM files. It's also only needed if you are following Peter's info on merging WebHelp or FlashHelp. I'm lost on whether it would be needed for merging AIR Help. Or even if AIR Help is capable of being merged. And I need to clarify further, when you create AIR Help output, there are two different types. One type packages things up as a single AIR file that you must ship to each user and have them install. The other type is web based AIR help that you copy to a server in much the same way you do WebHelp or FlashHelp.

Confused yet?

Cheers... Rick

Hello again

Okay, trying to dispel a bit of confusion with Build Tags and the like.

Consider RoboHelp to be much like your kitchen. It contains all the ingredients and tools to create any dish you like. For example, you might make a complete meal. Or you might create a batch of Chocolate Chip Cookies. All of it occurs in the kitchen.

Creating a merge is similar to preparing a Buffet. So the main project is like creating the Buffet table. And this Buffet table may contain any number of components that you choose. So when you design the Buffet table, you create spaces for the Green Beans. The Potatoes. The macaroni and cheese. The beef. The turkey. The chicken. All those items aren't exactly present in the Buffet, right? You have to create them later.

So you have another project that is used only to create the Green Beans that will be on the Buffet. And another that will create only the Potatoes. Each smaller component is a project of its own. But because the Buffet table has a space for it, it will present it if you create it. That's what a merge is like. You are able to add and subtract different elements after the fact and the end consumer is none the wiser. For example, if you remove Potatoes and supply Sweet Potatoes instead, the next person visiting the Buffet has no idea that Potatoes were there before. Or they could be removed entirely with the same result.

Conditional Build Tags are used during the preparation of any final dish you prepare. For example, perhaps you are making Chocolate Chip Cookies and your recipe calls for Walnuts to be part of it. You have an ability to say, for this recipe, uncle John is allergic to walnuts. So when I make this batch, leave the walnuts out. You applied a condition to making that recipe. Same goes with RoboHelp. You tag what you wish to control. Then when you prepare using the recipe (Single Source Layout is the recipe here) the Conditional Build Expression handles stripping out what you wish to leave behind. So if that's a CHM file, it's going to be missing the tagged content. If it's WebHelp, the information isn't in the output files. If it's AIRHelp, the information isn't in the install package.

Does that make better sense? I hope so... Rick

Some points of clarification.

• A help output that links opens another help output is NOT merged help just by virtue of that link. Without being set up as merged help, the search will be limited to whichever output is being referenced at the time.
• If set up as merged help then if the help is opened via the parent project, then the search will cover all the child projects first.
• As Rick has pointed out, only merged webhelp or flashhelp require the redirect.

The first two points above do of course mean the answer to your original question is Yes.

OK with that out of the way, I suggest the first thing is to get merged webhelp working as if you cannot get that to work, you are unlikely to get merged desktop AIR help to work.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

And to throw another thing into the "mix" - what about the new "Content Categories" feature? Can you serve up a specific batch of help without showing all the other variations? We're starting to talk about using this for one of our products that currently just has 1 version of the help locally installed. Now we're thinking of using Content Categories to show a second version of help within the same RH project.

That's good to know - I'd definitely be interested in keeping searches within each version's "silo" - so that's exactly what I need. What I don't know is if a user can access both versions of the help within the project - I think I need to do some testing/researching with this whole thing before I commit to it. So far, we've just been "blue-skying" the whole concept around here...

Yes, I'd be prepared to do that anyway - it's the initial presentation to the user I'd be worried about - if running version A of the app, then only let them see version A of the AIRHelp's Content Category for that app. That's the part I'm unsure of.

Karen

Apologies. Browser Based (BB) AIR Help does indeed also require the redirect. I would need to set up a test again to check that Desktop (locally installed) AIR Help also requires that redirect but I believe it does.

I recommend that you don't have content in the parent but that's your call.

You say you generated the output. Is that for both projects and are you testing after you have installed the help? You can preview after generating AIR Help but a number of things will not work from there and merged help is one. It looks like you are trying to merge desktop AIR help. I repeat you would do better to start with merged webhelp. Also please work with the download from my site to get things working.

On Content Categories, it is not necessarily the case that you will need separate topics for each category. Sure you will need some topics that may be unique to each category such as Introduction to Category A and Introduction to Category B. Even there though it may be that 80% of the content is the same and you could use CBTs to produce the two output topics from one source topic.

If you want to go for brain fryup, you can have merged help with content categories! I strongly recommending just forgetting that for now and focussing on generating a merged webhelp output. Once that is working, the move to merged AIR help will be done from a better foundation.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

"go for brain fryup" - Love it!

Karen

'I am a "visual" learner.'

You are an author writing instructions for people to follow yet you won't do just that yourself. Please forget AIR just at this stage and forget your own projects. Generate webhelp and generate the parent and the children using my demo. If you cannot get the demo to work with webhelp, then I will help you.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

LOL, sorta conjures images of frying pans with sizzling Gopher brains!

Yummmm!

hylandwriter1 wrote:

Sat down with a co-worker yesterday and she saw a few naming conventions that were "off" as well as a path that was incorrect.

Do you mean on your part or mine? If mine, where?

hylandwriter1 wrote:

The instructions say that the parent creates the "mergedProjects" folder.

I see you are continuing to try to get this working with AIR Help despite my having repeatedly said to learn how this works with webhelp. You are effectively trying to run before you can walk. I am sorry but I cannot help you if you will not work with me.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

First, no offence taken. I simply wanted to know the instructions were OK.

Second, it took me some time to get merged AIR help to work. I would expect that anyone trying to merge for the first time would have great difficulty if they start with merging AIR help. You HAVE to understand the process with merged webhelp first. That is what I mean by learning to walk.

Save yourself (and me!) a lot of grief by making merged webhelp work first. Please.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

I'm not sure how you have managed it as trust me, mergedProjects is created automatically in the correct location and if you have to create it, the merge doesn't work.

Assuming you have tested the index and search is working across the whole merge, then that is all that matters.

Well done and glad you sorted it, for your sake as well as mine.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge