manipulating headers / footers through API?

[Rick Quatro]

Hi Jakob,

Instead of adding text to the footer directly, you can add variables to the 
footers. Then, use your API client to modify the variables' values.

You are right that text frames are graphics. The FDK has a function for 
determining if a graphic is a text frame, etc. Header/Footer text frames are 
untagged, that is, their flow name is a NULL string; you can use this to 
distinguish them from main flow text frames on the master pages.

You may find this easier to code with FrameScript rather than the FDK. 
FrameScript has functions for reading and writing INI files.

Rick Quatro
Carmen Publishing
585-659-8267
www.frameexpert.com


Hello,

I'm currently exploring the feasibility to modify/update what is
displayed in the running footer through an API client which reads
information from an initialization file, and updates the footer
accordingly, like this:

maker.ini
----------------8<----------------8<----------------
[MyInitSection]
initfile = TestInit.ini

TestInit.ini
----------------8<----------------8<----------------
[Publication1]
FooterCenter="DRAFT"
FooterBinding="January 2006"


Now, it can't be very hard to read these configuration settings from
within an API client.  However, what I'm currently struggling with is
how to access the footer of my document.  So far, I've found this:

FO_MasterPage
-> FP_PageFrame (which is a FO_UnanchoredFrame)
   -> FP_FirstGraphicInFrame and then
   -> FP_NextGraphicInFrame (apparently TextFrames are "graphics")
      -> use this object's objId with F_ApiGetText
      -> and then F_ApiDeleteText and F_ApiAddText

All this comes from reading the FDK reference and the FDK Guide. As I
said I'm investigating this because we may hire a programmer to do
this (and more), but I'm no C++ programmer myself, so testing out the
above would take me quite some time.

BTW, we're currently updating the information in the footer through
text insets located in a separate file (I guess that this may be your
first suggestion to "do it another way"), but we'd like to centralize
information like this in one easy-to-manage configuration text file
for each publication.

Thanks in advance.
--
cheers,
Jakob.
_______________________________________________