As I understand what you are stating, each book component will store the value of the book file title attribute value which existed the last time the generate/update action was taken on the book file. Thus, if the value of the attribute in the book file is changed but the generate/update action is not executed, the component files within the book will retain the book title which existed the last time the book file was updated.
Furthermore, using the solution you describe, each time you change the book title in the book file, you must convert each individual book component file to MIF and "fish out" the current attribute value in order to produce the desired running header or footer. To make this work, therefore, each time the book file attribute is changed, you must always execute the generate update action on the book file, convert each book component file to MIF, fish out the current value of the book title attribute in each book component file, and use it to produce the correct header or footer text, and then reopen it as an ordinary FrameMaker file. That, it seems to me, could be an onerous and error-prone task, even if you use FrameScript. This method also implies that access to all the individual book component files must be blocked each time the book file attribute value is changed, and each component file must remain blocked until the generate/update action on the book file is executed, and the fishing expedition to replace the old book title is repeated in all the component files. It seems to me to be far simmpler to repeat the book title attribute in the topmost element of each component file, and update the attribute value in each component file when the attribute value in the book file is changed, which is much easier (and perhaps quicker and more reliable) than the method you are proposing. My alternative solution to the problem becomes even more necessary when one or more component files are included in more than one book file, each having a different book title. In that situation, the last book file on which the generate/update action was taken will determine the book title in the running header/footers of those component files. Thus, if an individual component file is printed separately (as is often necessary), the book title which appears in the output will often be the wrong title for the intended usage, which will be particularly confusing when different versions of the document are produced using conditional text settings to differentiate between version. =================================== --- Rick Quatro <frameexpert at truevine.net> wrote: > Thanks for your reply. I got the message below rom > Mark O'Connor offlist. > The book information is stored in each file, which > is nice because the attribute values carry over, even if you don't have the book. You have to > save the document as MIF and fish out the > information, but at least it's > there. As far as I can tell, you can't get the > information directly from the > document with FrameScript or the FDK. > ----- Original Message ----- > From: "O'CONNOR Mark" > Hi Rick, > The format is [attribute name:element name]. If > you don't specify the > element name, the first occurrence of the attribute > on the page will be > used (blank if there are no occurrences). If you > specify an element > name, it will use the first occurrence on the page: > if there are no > occurrences it will use the value of the first > parent element that uses > the attribute (and blank if no parent elements use > the attribute). > The "book" element information is contained within > the file, but > you'll need to save the file as mif to find it (look > for > "DBookElementHierarchy"). I believe that this info > is updated by the > generate/update command. > Cheers, > Mark O'C > >