Hello,

 

We have a long document as a single record. I am trying to build a table of contents when we save as PDF. I need to determine the page number of the subheadings, which are fields. I have a script that pulls the subhead and its correct page number, but only if I can get it to the correct page by go to last then go to previous. The problem is I do not know what page the field will be on.

 

Under the subheads are numerous sliding up fields.

 

thanks,

Jim

It's difficult enough to tell which record is on which page - and you are asking about individual fields? I am not sure that's even possible. How many of these subheadings do you have?

There are 88 subheadings.

I started a script that goes to last page, and looks for the last subhead. The thought was to walk upwards from there. But unfortunately I am stuck as verifying the page number. If there was only a way to test if not on current page returns a 0.

 

The wording of each subheading is known and cannot be altered by the user.

 

Jim

I started a script that goes to last page, and looks for the last subhead.

 

I don't see how that road can lead to anywhere. When you are in Preview mode, you cannot "look for the last subhead" (other than manually, that is). Conversely, when in Browse mode, you can't tell on which page a layout element will end up, since Filemaker paginates "on-the-fly".

 

 

There are 88 subheadings.

 

Ouch. In that case, I am not going to expand on an idea I had - as it would necessitate creating (and maintaining!) 88 layouts...

 

Why don't you switch to a multiple records structure, with sub-summary parts instead of subheadings? That way producing a table of contents would become, if nor exactly easy, at least reasonably feasible - see:

http://fmforums.com/forum/showtopic.php?tid/144352/post/144371/#144371

I am not seeing how that would work as there are currently 12 layouts with some layouts max on length.

 

I am not even sure if making a report would work either.

 

 

thanks,

Jim

I am not even sure if making a report would work either.

 

It depends on how your document is built - you haven't told us much about that. If it's made up of similarly formatted articles (such as a contract, for example) then having each article in a separate record would greatly simplify things. For one thing, youd only need one layout and the body part would not have to be taller than the height of the longest article.

Let's ignore the troubling issues you have with your structure here (88 subheadings = 88 fields, just for subheadings, right?).

 

You could probably do this with conditional formatting.

 

For each of the subheadings, try adding a conditional calculation:

Let(

$$subheading [Code ( table::subheading ) ] = Get ( PageNumber ) ;

""

)

 

Loop through the document in Preview mode, with a refresh after each Next Page. Then you have a list of page numbers coded by subheading name.

 

I think that should work though I haven't tested it.

You could probably do this with conditional formatting.

 

Ha! Nice example of out-of-box thinking. I just tested this with a traditional report using sub-summaries and it does work. A bit slow (it takes about a second per page to produce the array), but at least it provides Jim with an alternative to fixing his structure...