Help decoding Running H/F variables with attibutes

[Daniel Emory]

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
> 
>