This content has been marked as final. Show 27 replies
Do a multi file search on
That will confirm beyond doubt there are no merged cells.
If you use FAR from http://www.helpware.net, you could easily remove all the tables in the project. Then you should be able to compile. I realise that won't be an acceptable output but it will prove tables are part of the issue.
Then we can start pinpointing.
Thanks for the tip.
I proceeded by removing all the merged cells that remained in the project: RH6 still crashed.
I then deleted all the tables in my project: the project compiled fine.
So yes, the problem does seem to root from tables... Big problem though because this particular project contains a great number of more or less large tables. Without them, the project does not have much purpose...
Now that this has been pinpointed, what to do next?
Again thanks for all your support and for have pinpointed the root fo the problem... My hair was dangerously starting to thin out ! :-)
Here's how I would track down the offending table but the number of them might be an issue.
Using a disposable copy of the project, and with a list of all topics with <td_null> in them, in Project Manager delete half those topics. Then generate using a condition. If that has not fixed it, do the same again until you track down the offending table(s). If it did fix it, start again with another copy and just delete half of the first half you deleted. A pain I know.
One thing I don't think we have tried. Exclude all the topics with tables using a build expression. It will either work or compound the problem. You could try that with a new test project.
One small but important point: At first we thought a table would cause trouble if it had both a conditional tag and merged vertical cells in the last column.
It turns out (Peter updated his discussion to reflect this), it doesn't matter where a conditional tag is applied in the project. All you need is
(1) to apply a conditional build tag when generating WebHelp, and
(2) a table anywhere in the project with merged vertical cells in the last column.
The <td_null> expression appears anywhere you have merged cells and is harmless unless a table has merged cells only in the last column, merged vertically. Merging, for example, adjacent cells in columns 3 and 4 to make column 3 the last in the row does not cause a problem.
When you finally track down the table at fault, please post back if you find a different condition in a "bad" table.
Agreed. The problem is you cannot search for tables with <td_null> just in the end column.
Small but important change
(2) a table anywhere in the project with merged vertical cells ONLY in the last column.
Of course we might find some other scenario but that's it at the moment.
But there could be <td_null> elsewhere so while that will find merged cells in the end column, they are not necessarily the only merged cells in the table. If there is a merged cell somewhere else in the table, it is not going to cause the crash.
However that would at least get the potential number of tables down. It would probably be possible to then identify the rogue ones. I'll play later.
Ok. I think my recent crash-fest is also stemming from this problem, but I'm not entirely sure. If I do a build with a conditional build expression, then yes my project crashes. Without the conditional build expression it compiles fine.
So I'm a little confused here... are we saying any merged cells will cause problems if conditional build tags are used anywhere else in the project? Or do the merged cells and the conditional build tags have to be in the same topic?
Re: So I'm a little confused here... are we saying any merged cells will cause problems if conditional build tags are used anywhere else in the project? Or do the merged cells and the conditional build tags have to be in the same topic?
My understanding and experience is 'merged cells will cause problems if conditional build tags are used anywhere else in the project? ' Peter has recently updated the snippet on his site to make this very clear.
So how does this work out? I have 36 topics that use merged cells and most of them need to continue to use them.
So it sounds like we have to do one of two things then:
1) Remove all merged cells
2) Remove all conditional build tags
Is that right?
Can anyone say "patch"?
READ THE SNIPPET
It explains what to do to your table to stop it being an issue. Your table will not look any different to the end user.
A quick review of the steps.
Leave the conditional tags as they are.
1. Search for <td_null></tr> in topics. List the topics that contain this string.
2. Examine each of these topics for a table that contains vertically merged cells only in the last column, and no other merged cells in that table.
3. Three options:
(a) Revise the table structure so the last column has no vertically merged cells.
(b) Find a valid reason to merge cells elsewhere in the table, so the table has merged cells in more than one place, and leave the vertically merged cells in the last column as they were.
(c) Use Peter's clever workaround of adding a blank column to the offending table.
4. Repeat for all tables that meet the criteria in step 2.
5. Use conditional tags in any manner as you need them, anywhere in the project, including (or not) in the tables you have fixed.
6. Generate WebHelp using (or not using) a conditional build expression.
If our analysis is correct, the project should not fail.
If it fails again, consider copying the entire project folder and, in RH, deleting all topics with tables, and generating WebHelp.
If it runs OK without tables, re-import a batch of the deleted topics and generate again. Continue removing and adding back topics until the rogue table reveals its presence.
By the way, you haven't said whether your !SSL! directory contains a WebHelp output folder with at least some topics generated before the crash. This would be very useful to know.
Thanks everyone! I didn't see Peter's workaround the first time I sped read through his snippet section. Makes sense now. I removed all merges in the right most column and my copy project and it builds fine. I'll need to go back through the actual one and put in those extra columns.
Thanks everybody (especially Peter). I fixed the problem and indeed it was just one table that had merged verical cells in the last column. Unmerged them and the project now compiles fine. Note that I tried Peter's workaround to majke an extra column at the end of the table and apply a conditional buid tag on it to make it disappear in my output but this column is unfortunately still there...
I assume you did include the tag used on the column in the build expression.
I could envisage some table settings would cause the other columns not to resize but I cannot see how the column would fail to dissappear.
Try some more and post back if still stuck.
Ok am I just really um up a creek without a paddle, lucky me my tech writers used a template which had a merged cell in 5+ locations per topic for every topic in multiple documents (1k+). Should I give up now format and reinstall Robohelp5, or does adobe plan to develop a fix for this issue?
If they are planning to develop a fix sometime in the "near" future then I will work on the template and start unmerging all the tables all 5k of them. If not its just to much of a risk for me to face with each publish as we always import from word.
Do we know if this issue exsists with PDFs? I could potentially convert the project word docs to PDFs and reload. Could be faster cause I can bulk convert the pdfs, instead of having to alter all the html files.
Also any fast tricks to add a column IE: /find <td_null> and then I could determine if it was which in my case is everytime, I could then just past some html below it and move on with life. That would be great.
Sorry but I have no idea what is happening about releasing a patch.
I wonder if Macro Express would be a good way of automating the addition of a column. 30 day free trial should enable you to test that. :-)
You may find you can reinstall X5 without reformatting as the two versions can co-exist. As with any such installation, it is a risk but one I think I would give a go.
I used the trial version of RH X6 to convert a copy an X5 project for a test. After I uninstalled X6, RH X5 couldn't open the X6 version (glad I saved a copy of the X5 original).
Are we clear on the fatal condition?
Merged cells by themselves are not the problem.
The failure is triggered when one or more tables has cells merged vertically only in the last column, and no other merged cells, and you apply a conditional build tag (no matter where the tag is applied in the project).
You will find tables to examine by searching for <td_null></tr>. But if a table also has merged cells elsewhere, that's OK.
Are you saying the template had merged vertical cells only in the last column of a table for 5 tables in each topic, and no other merged cells in the same tables?
Hkabaker yeap the template has vertically merged cells in the last column for each table which is 5 per topic cause they used it as a header bar to break documents down into sections. Note: I did not make the template or I would have shot it down long time ago.
I am just tasked with fixing the issue.
The team also uses build tags for just about every single topic in the project. They use build tags as an archiving function as well as a "team" release marker so we can publish to a few different teams.
To amend my comment about going back to X5:
As Peter has suggested, you can go home again.
I opened a project from RH X5 in the RH X6 trial version and did some work in the new version.
I uninstalled RH X6 and re-installed RH5x, updated to 5.0.2.
X5 complained about the project being from a newer version of RH and would not open it.
I removed the .cpd file from the project folder, and X5 was happy to open the project .xpj file and rebuild the .cpd file.
well lucky for me I had a development environement setup to test run the conversion over to RH6, so my current project was / is ok, just not overly thrilled about the coins we put into RH6 before identifying the issue, lol. Time to talk to finance and see about refunds, unless it seems that Adobe is going to fix the issue at some point.
I don't have any information on a patch being issued, sorry.
Thank you Peter for your detailed explanations - and to all for the problem solving tips. Especially HKabaker for how to get a project to open in version 5 after it had been touched by version 6 (worked beautifully!)
We had upgraded 2 copies of Robohelp to version 6 in order to get one of the new features: the ability to apply conditional build tags to books. I was needless to say stunned to find out about the bug outlined in this thread!!! We have many pages in many projects that are formatted using tables, and which contain conditional build tags. Manually searching for and fixing problem cells in tables is NOT an option for us.
I'm really disappointed that there could be this big of a bug sitting out there, unresolved, with no word on when it will be fixed (I see the first post on this was a month ago). I've had one machine rolled back to version 5, and am doing the same with the other - and asking for a refund.
Please contact me via my website.
Thanks fo this update that resolves this issue.
Small question though: in the technote it only mentions the patch fixes the problems when generating a chm file.
howevern this problem involves every output generate by RH6. Can you confirm or infirm that the problem is fixed for every output supported by RH6?