Writer variables in two databases

[jKaufmann]

WG60 (I believe the most current Writer Guide) says that one way to define variables (particularly, but not limited to, text values) for use in a document is in “Custom Properties”:
(File > Properties > Custom Properties).
Unfortunately, variables defined that way (as opposed to being defined by “Set variable”) do not show (for insertion in the document) in the “Show variables” list:
(Insert > Field > More Fields > Variables tab > Show variable).
Instead, they show in, and are inserted from, the Custom DocInformation list:
(Insert > Field > More Fields > DocInformation tab > Custom).

So variables for the document are stored in two databases. That just seems wrong, unnecessarily cumbersome to use, and possibly dangerous. (For example, what happens if the same variable is defined in both places?) Am I missing something basic about this? - is there an advantage to having two different datasets? [The Help and Writer Guide both seem to be silent on this issue.]

john

[ajlittoz]

There is conceptually a single “dictionary” for all fields. As you noted, the fields are sorted in different categories. Each category corresponds to one tab of the Insert>Field>More Fields dialogs. A category in its turn groups several “types”.

When you consider the final object and its effect, you end up with tens of “datasets” according to you words. This is what make Writer fields so powerful.

You made however a mistake in your question with word variable.

In Writer, a variable is an object whose value can be changed dynamically in the text flow with a special Set variable field. Therefore, a custom property is not a variable though its value can be changed through File>Properties. A property has a fixed value during text layout. No field can change it.

A property is some invariant value for a given document even if fancy effects can be achieved with it (such as changing visible document content).

A variable value can be freely changed every so many words in the document to create context-sensitive formatting or content.

Variables and properties don’t serve the same purpose.

To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!

[jKaufmann]

Whether variables and properties serve the same purpose is precisely the question. Let’s say, for example, you have a report that changes periodically, maybe weekly. For the benefit of readers of the document, the report’s date is in the document in a number of places. You don’t edit that date in every instance; you make the date a text field, and change it in one place, and the text fields then change everywhere. Is that date a property of the document or a variable of the document text? You can do it either way, for the same purpose, so there seems to be a distinction without a difference.

Understanding that distinction would put this question to rest, so you have raised an important point of which I have been vaguely aware but not conversant. I have tried to remedy that deficiency by studying the Help and Writer Guide, but both seem silent on an overview of “More Fields” and their uses. Is there another or more appropriate document for this purpose?

[ajlittoz]

i don’t think there is any documentation on this topic.

I personally use the properties for “semi-permanent” data, like document version, date of writing or publication, copyright details. This looks like the category of information you have with your report date. This is set for the document and will not change in the middle.

And the nice thing is the UI to set the value is quite user-friendly: all properties are listed in a single place and it is easy to change them with an assurance of global consistency (relative to each other).

I use variables only if the data has a reason to change in the middle of the document. For instance, I had a case where I needed to detect the end of a chapter. The beginning of a chapter is easy: it is usually associated with a Heading n paragraph, but the end is quite difficult. For this I set a variable to 0 at the start of a chapter and insert a Set variable field at the very end of the last chapter paragraph setting the variable to 1. …

[ajlittoz]

(continued) The flag can then be used for whatever formatting change is needed. Note however this trick is limited by a misconception in header/footer management: they are computed only once at start of page sequence and never again afterwards. Consequently a dynamic header or footer based on variable value is useless.

I generally avoid variables because hunting for their occurrences in the document is not user-friendly at all.

An area where variables are compulsory is hidden text/paragraph based on a value. The value must be taken in a variable and can’t be from a property. To make things worse, I don’t know of any way to transfer a property value into a variable. Thus “configuration” of a document can’t be driven from the properties. You must make provision for an area to host all your “hiding” variables.

[jKaufmann]

What a GREAT answer! I thought I knew LO fairly well, but you have informed my use immensely. Thank you.

[ajlittoz]

You’re welcome. If you’re satisfied with my answer and comments, please tick the answer and perhaps upvote it.