# Again with the running heads...

I have a strange thing happening with the section numbers in my running heads.I can fix it manually as a layout adjustment for each occurrence, which isn't so bad when there are just a few pages. I would prefer that they work correctly, though.

On some pages they appear correctly:

But on a page where a section begins, I just get that section number:

In this case, "3" is the chapter number and is called into the header independently. Below are some of the macros I use. Let me know if I need to show anything else.

Any solutions?

Thank you!

-Carol

Parents
• Hi Carol,

One missing piece that you've not provided is the definition of the "bna.id" macro.

I don't know if you've done it on purpose, but one observation I have is that your macros named with semi-colons in them, like "bna.id;4" and "bna.id;5", will never work (at least not in Classic mode). The XPP software seeing a <bna.id;4;3> macro would grab the macro name stopping at the first semi-colon and so would only lookup a macro named "bna.id" (and thus never find a macro named "bna.id;4"). But perhaps you've done this on purpose in the spec (adding semi-colons to macro names) to "document" some macro history.

Getting back to the "bna.id" macro, I think Chris may have been on the right track. Given that the definition of "!bna.id" starts with <ce;45> my guess would be that the definition of "bna.id" would have <cs;45>.

So that would mean that in that "wrong line" you have a <cs;45>...<ce;45> capture of "a." (from "bna.id" to "!bna.id") followed by a <px;;45>...<pa> capture of "E.5.a." (from "bnaidhf") - in the same line. And as Chris said, if your <tr> callout in the frill is using 'f' (first) then you'll only get "A." (capitalized) and be missing the "E.5." - just as it appears to be the case.

One possible solution might be to resolve the text register 45 conflict by using a different capture register for one of the two macros or another possible solution would be to rework the order in the data such that the <bna.id> macro follows the <bnaidhf> macro. All depends on everything else going on in your "setup".

Jonathan Dagresta
SDL XPP Engineering

• Hi Carol,

One missing piece that you've not provided is the definition of the "bna.id" macro.

I don't know if you've done it on purpose, but one observation I have is that your macros named with semi-colons in them, like "bna.id;4" and "bna.id;5", will never work (at least not in Classic mode). The XPP software seeing a <bna.id;4;3> macro would grab the macro name stopping at the first semi-colon and so would only lookup a macro named "bna.id" (and thus never find a macro named "bna.id;4"). But perhaps you've done this on purpose in the spec (adding semi-colons to macro names) to "document" some macro history.

Getting back to the "bna.id" macro, I think Chris may have been on the right track. Given that the definition of "!bna.id" starts with <ce;45> my guess would be that the definition of "bna.id" would have <cs;45>.

So that would mean that in that "wrong line" you have a <cs;45>...<ce;45> capture of "a." (from "bna.id" to "!bna.id") followed by a <px;;45>...<pa> capture of "E.5.a." (from "bnaidhf") - in the same line. And as Chris said, if your <tr> callout in the frill is using 'f' (first) then you'll only get "A." (capitalized) and be missing the "E.5." - just as it appears to be the case.

One possible solution might be to resolve the text register 45 conflict by using a different capture register for one of the two macros or another possible solution would be to rework the order in the data such that the <bna.id> macro follows the <bnaidhf> macro. All depends on everything else going on in your "setup".

Jonathan Dagresta
SDL XPP Engineering

Children