When a variable (type "user field" or type "variable") has the same name but is inserted with different formats (Text vs. General), there is an interaction between them, in terms of what is displayed, which seems wrong. (could not find any relevant documentation) Case 1 (user field) 1. Insert variable type "user field" with "General" format, and a text string value. Actual: 0 is shown. 2. Insert another "user field", with same variable name, "Text" format, and a text string value. Actual: The text value is also shown in the first user field as well. (i.e., the "General" format is, in effect, overridden). Case 2 (variable) 1. Use "set variable" to insert a variable field with "General" format, and a text string value. Actual: Nothing is shown. 2. Insert another "variable" field, with same variable name as the first, but "Text" format, and a text string value. Actual: The text value that was entered for the first variable is now shown, even though the format is "General". In short, these two cases show how the same variable name with different formats result in "General" format fields being able to show text. Is that to be expected?
Case 1: 1. looks wrong to me, but might be intentional (in sense of Word compatible behaviour). Having seen the code lately I'm tending more to assume a bug here though.. 2. if you hit the check mark button that's expected; not sure what should happen if you didn't. There is no "other user field with same name", user fields are document global. But the state looks messy. Case 2: 1. similar to case 1. 2. similar to case 2, but there should be two instances of the variable; apparently setting a new triggers redisplaying the first. Things are a little more obvious if text1 and text2 (i.e. different texts) are used for each step. Behaviour is the same already in OOo.
> Case 2: > 2. similar to case 2, to case 1 of course..
See bug 146737, comment 8 for an additional point that saving and reloading the document with the variables that have the same name, but different formats, results in changing the format to the last inserted instance.
Dear sdc.blanco, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug