Condition tags are breaking my targets

[kcann]

Hi

I've noticed that some of my output targets suddenly stop working and return an 'index out of range' error. I've narrowed the problem down to the condition tags, but I'm not sure why they work for a while and then stop working. This applies to both PDF and WebHelp targets.

Tech Support are working on this as well, but I wonder if anyone has experienced (and fixed!) this problem before?

Thanks!

Karen

[LTinker68]

Is it bombing during the build, or does it build but then bomb when you try to open the output? If it bombs during the build, does it happen on the same topic? If so, maybe you could remove the condition tags from that topic (including opening the file in the Internal Text Editor to make sure the tags were completely stripped out), then reapply the condition tags and see if it builds ok. Or at least gets past that topic before it bombs, in which case you repeat the process on the next topic that bombs.

[kcann]

Hi Lisa

It fails during the build, on different topics, never consistent. And the builds fail randomly - they work for a while, and then suddenly fail. I've narrowed the problem down to some specific condition tags, but I have no idea why these, in particular, should suddenly cause the build to fail.

Thanks!

Karen

[kcann]

Tech support have narrowed the problem down to conditions applied to <tr> elements.

Karen

[TheGreatAndPowerfulOz]

Tech support have narrowed the problem down to conditions applied to <tr> elements.

Karen

I realize this is a very old post, but I just ran into this issue today when trying to generate a PDF target. It seems that a fix in Flare to allow conditional tags on <tr> elements has still not been provided (I'm using Flare 9.1.1). I'm going to submit the issue as a bug.

Thankfully, I checked the forum this morning when I got the "index was out of range" error. I read this post (among others), so I at least had an idea of what I might look for. By process of elimination, I found the one snippet in my project that was causing the error. Then, as soon as I spotted a couple of <tr> elements therein with a conditional tag applied, I knew what to do to work around the issue!

In my case, the conditional tag simply served to exclude the table row from output. So, rather than...

Code: Select all

<tr MadCap:conditions="MyConditionalTagThatExcludesRowFromOutput">
    <td>some content</td>
</tr>

... I just commented the <tr> element out, as follows:

Code: Select all

<!-- <tr>
    <td>some content</td>
</tr> -->

Of course, the comment marks within the table now cause a "Found non-table row inside table section" message to appear whenever I save the snippet, or when I generate any output that contains the snippet. The message doesn't prevent successful generation of output, however, so I can live with it for now!

[shgadd]

I too suddenly started experiencing this error today. What a pain! I've been successfully using condition tags on <tr> elements for weeks, added another one today and suddenly Flare no like.

I'll join you in submitting a bug.

[TheGreatAndPowerfulOz]

MadCap is currently looking into the bug I submitted; they asked me to ZIP my project up and send it to them so they could attempt to reproduce the issue.

I noticed two things, in particular, while writing up the bug:

1) In order for the build error to occur, the conditional tag applied must be one that causes the content to be excluded from output (if only conditional tags that are included in output are used, there will be no error).

2) If an "excluded" conditional tag is applied to a row near the top of the table (the exact location varies), there is typically no build error. Applying the tag further down in the table, or on the bottom row, will cause the build error.