Included Topic not working

Please post all questions and comments regarding Help & Manual 7 here.

Moderators: Alexander Halser, Tim Green

Post Reply
User avatar
Rob Davis
Posts: 146
Joined: Tue Sep 06, 2011 9:45 am

Included Topic not working

Unread post by Rob Davis »

Hi
We wrote a topic that wuld be included i several projects.
Worked fine, we published the projects and the included topic came across perfectly using the tailored ToC just as planned.

Now, one of the projects shows the included topic in the main ToC, but with a red dot and without its 'expansion' below. I tried it again by adding the external topic and it came across fine. - See the attached screenshos.
Any idea what happened?
When we see the little red dot in the ToC entry, how can we see what is wrong? the Topic entry in the right-hand window only gives the topic name - cant see the path or any information about exactly what 'should' be coming across!

Any explanation would be helpful, thanks.

Rob
You do not have the required permissions to view the files attached to this post.
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Included Topic not working

Unread post by Tim Green »

Hi Rob,

The red circle with an exclamation mark in it on merged project nodes in the TOC means that the merged project can't be found. Something has changed in the position of the project relative to the project it's being merged into since the node was created. This can always be fixed by deleting the node and re-inserting it. It is really just a simple link, so it's a quick process. :)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Rob Davis
Posts: 146
Joined: Tue Sep 06, 2011 9:45 am

Re: Included Topic not working

Unread post by Rob Davis »

Hi Tim
Thanks for the response. The problem went away and has returned!
Just to confirm a suspicion - is it mandatory that the master project is a .hmxp? On the current incarnation of the problem, it is solved if we use a .hmxp, and recurs if we try the same thing as a .hmxz (even with deleting and re-adding the sub-project, it works with the uncompressed one and fails with the compressed).
I don't see an explicit rule about this in the documentation - but I want to confirm the suspicion - .hmxp is mandatory for the Master?
Thanks
Rob
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Included Topic not working

Unread post by Tim Green »

Hi Rob,

HMXP definitely isn't mandatory for the master, although you really should be working in HMXP if your project is large and complex enough to have sub-projects, just as a basic principle. The red warning icon on a child project node simply indicates that that project can no longer be found in the location in which it was inserted.

Just as a point of terminology, note that those are sub-projects, not external topics. Binding into the TOC like that is always an entire project. Individual topics can't be linked into the TOC, you can only insert them in an already existing topic as snippets.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Rob Davis
Posts: 146
Joined: Tue Sep 06, 2011 9:45 am

Re: Included Topic not working

Unread post by Rob Davis »

Hi Thanks. Tim

Well, you shot down my theory, so I will have to keep hunting till I figure why this is giving me trouble.

Regarding whether the project is large enough to justify being an hmxp - I really dont know how to judge. When I joined, I inherited several really large Help hmxp files to maintain. We were in a crises after the previous TW left, so I just jumped in. Later, I started appreciating the 'single-source' aspects, and started using H&M for all sorts of smaller product Manuals - including several where no Help files were involved - just pdf output and in a few cases, some Web pages.
We have evolved a method for maintaining several different 'master' projects, and adding in Topics covering shared identical sub-projects when the particular product supports that feature.
I'm pretty sure that we could do better if we sat back and architected the whole thing again - but in this business, I've found that there is seldom time and never budget for that kind of refinement.

On that note - If H&M / EC Software were to organize a seminar / working group, I for one would love to be able to swap ideas and maybe see how others deal with similar issues.

Meantime -as always, thanks for the quick and helpful responses.

Rob
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Included Topic not working

Unread post by Tim Green »

Hi Rob,
Regarding whether the project is large enough to justify being an hmxp - I really dont know how to judge.
I wouldn't make it dependent on the size. If it's important and if you work on it regularly, use HMXP.

Even though HM7 now has the automatic rescue copy system in the event of Windows crashes, uncompressed projects are still way better protected against data disasters. A HMXZ is a single-file compressed binary, actually a zip. More than minimal damage to that makes the entire project inaccessible. Even if the components of a HMXP are damaged you can always recover the undamaged portions because all files are plain text XML, and you will almost never have damage to more than a couple of individual files.

In addition to that HMXP supports version control, native multi-user editing, translation with external translation memory tools like Trados and incremental backup with tools like AJC Active Backup.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Rob Davis
Posts: 146
Joined: Tue Sep 06, 2011 9:45 am

Re: Included Topic not working

Unread post by Rob Davis »

Hi Tim
Thanks - I hear you, and will look at rehousing the projects and keeping them as .hmxp's.

Observation/Question:
A couple of our writers got into long, long 'nests' of folders, because they would save new project versions using 'Save As', and as the projects were 'hmxp's, they would be asked if a new folder should be created - they would simply accept the choice.
It would seem to me that the option should offer a new location at the same level, and not 'nest' down - then we could easily have
'Product A' with subfolders
Product A_v1
Product A_v2
Product A_v3,
rather than what we finished up with before I caught it:
Product A
....Product A_v1
........Product A_v2
................ Product A_v3
Are we missing some simple logic here?

And a suggestion - perhaps for the Wish List:
As new versions were released we were getting steadily longer Search paths, and we were sometimes overwriting older graphics for a new version and then finding that we needed to publish the older version. We made a VBA script that takes the list of graphics from the Project Report, and makes a copy of all the graphics - regardless of path - into a new, single folder that we can designate. It takes wild cards, so we get to copy both the .ipp AND its source .png.
Do you think you might integrate a tool like this? - something like 'Save all graphics to new folder'?
This allows us to have a fresh new project with a single entry in the Search path, while still leaving all the old graphics where they were, and with their existing names.
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Included Topic not working

Unread post by Tim Green »

Hi Rob,

You definitely don't need to nest folders, and project folders nested inside other project folders (i.e. an HMXP project inside another one) are a bad idea and and could possibly be a source of project search path problems. I'd recommend treating HMXP project folders in the same way as HMXZ files -- they are actually really the same thing, since a HMXP is just an unpacked HMXZ. Group them inside a single parent folder when it makes sense, and if they share images you can ideally put their common image folders inside the same parent folder.
It would seem to me that the option should offer a new location at the same level, and not 'nest' down - then we could easily have
Definitely. I wouldn't accept the suggestion uncritically. HM just makes it because if you already had a folder of HMXZ projects, putting the HMXP folders inside that would make sense.
Do you think you might integrate a tool like this? - something like 'Save all graphics to new folder'?
This allows us to have a fresh new project with a single entry in the Search path, while still leaving all the old graphics where they were, and with their existing names.
I'm not sure if this could be added, I'll look into it. But the Search Path structure is actually designed to allow you to consolidate your graphics folders as easily as possible. You can also do that with your existing projects: Just copy all your graphics to a single common folder, then delete all their search path settings and replace them with the one fresh reference. It makes everything clearer and it's a good way to reduce the chance of having accidental duplicate names.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Post Reply