Hello Chas,

Thank you for submitting the bug. I can confirm that the writer isnt saving the set variable value in master on Linux.

Version: 4.4.0.0.alpha0+
Build ID: df73f4115cfe4d07e4159adf087571687eb173ec
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-09-25_23:36:54

Still present on LO Writer 5.2.6.2 under Windows 10/x64

>Set_Variable VarA is (without the quotes)
seems to set VarA to the value of the variable "is" in Writer 5.3.3.1.  Additionally, it wants a number, in spite of the availability of "Text" formatting.
This might or might not be correct behavior; the documentation isn't at all clear.

IMO, this doesn't seem to be the *BEST* behavior, in that Perl (for example) states that a variable is a named string of characters that might or might not be interpretable as a number.  Yes, C++ proceeds to overload the + operator to mean concatenation, but plenty of BASIC languages since time immemorial have achieved this with operators (MID$) and casts, such as NUM$ and STR$.

still the same problem in Version: 6.1.0.0.alpha1+
Build ID: 8a2745e1beee722c8c9691c397e493cc1160bedf
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-30_23:34:23
Locale: nl-NL (nl_NL.UTF-8); Calc: group

I believe this is NAB (or maybe a documentation problem).

"Standard" no longer appears as a format, but I assume it is the same as "General" (where the same results can be obtained using LO 6.3.4.2)

General (and probably Standard) is a number format.  The procedure here is assigning a text string to a numerical variable. So it is understandable that Show Variable does not show anything.

If you right-click and edit field on the inserted variable and change "is" to a number -- then that number will be shown.

If you want to show an alphabetic string, then use the Text format.  It works as expected in LO 6.3.4.2

Given how long this bug has been here, I wonder what I have misunderstood.

sdc.blanco@youmail.dk 

In Microsoft Excel, the General format has the description "no specific format." If you type a number into a cell with that format, it treats it like a number. If you type text into a cell with that format, it treats it like text. So it is reasonable to expect that a field with the format "General" in LibreOffice would similarly adapt to whatever I type into it. It also offers other formats such as dates.

LibreOffice fields offer varying formats also including formats explicitly named as being numbers and formats explicitly named as being dates.

There is nothing in the field format list that initially displays to indicate that LibreOffice considers General to mean numeric. There is General, Text, and several numeric options. It is only when I further click Additional formats... that we see LibreOffice considers General to be a numeric format.

I recognize that LibreOffice is not Microsoft Office. That said, expecting users to realize that something called "General" is a numeric format or that the default for fields is to be a numeric format and that if you want text then you have to explicitly choose Text and not choose General, unlike Excel, then this is a usability issue for people who have to move between Microsoft and LibreOffice. At the very least, you could make it obvious by changing the label from General to General Numeric or, if you want it to be brief, Numeric.

(In reply to Chas Belov from comment #8)
> In Microsoft Excel, the General format has the description "no specific
> format." 
Ok.  The summary for the bug mentioned "Standard". No other information was given 
about which format was used for the variable.

Maybe the problem here is "documentation" and not a bug in Writer field variables?

> There is nothing in the field format list that initially displays to
> indicate that LibreOffice considers General to mean numeric. 

I agree that it is hard to interpret the meaning of the formats (and I could not find any documentation for "General" in "Help").

I will add needsUXeval.

Maybe a "tooltip" over some items in the Format list could help (a little).
(plus possible documentation improvements).

Adding Eike for the General vs. Text format question.

But I'm concerned that LibreOffice silently keeps the previous, correct value. If you set varA to 123 it's shown in the document. And this value remains there after changing the variable to "a456" - intentionally with the typo.

(In reply to Chas Belov from comment #8)
> In Microsoft Excel, the General format has the description "no specific
> format." If you type a number into a cell with that format, it treats it
> like a number. If you type text into a cell with that format, it treats it
> like text. So it is reasonable to expect that a field with the format
> "General" in LibreOffice would similarly adapt to whatever I type into it.
> It also offers other formats such as dates.

Sounds reasonable. Variables with the format general should be visible whether data is numeric of text.

(In reply to Heiko Tietze from comment #10)
> Adding Eike for the General vs. Text format question.
Just coming across this again because it was added as See Also to bug 154613.

Same statement as in https://bugs.documentfoundation.org/show_bug.cgi?id=154613#c1

The "Text" and "Formula" entries are UI resource strings, the "General" is a locale data dependent number format code keyword you also see in a table's or Calc's number format dialog, hence may change with the document locale.

I _believe_ the current implementation of not showing text if the General format was assigned is a bug, unless there was a reason for compatibility with Word.

Having taken a look at this and been trying: it makes no sense to display text content with the General or any other number format. Instead, when the input is not convertible to a number or date+time the Text format should be forced.

Reason is, saving the field to file a text:user-field-decl can be _either_ a office:value-type="string" text field with a string-value, _or_ an office:value-type="float" numeric field with value. While text:user-field-get theoretically could have a number style:data-style-name to a string text field applied and ignore it (then why even bother having the style), most implementations presumably would not handle that. Forcing an office:value-type="string" text field would be clean.

Writer's field handling isn't quite straight forward not to say convoluted.. someone familiar can debug that into existence..
Hints are SwUserFieldType, SwSetExpField and SwFieldVarPage::SubTypeHdl() and all nsSwGetSetExpType::GSE_STRING handling.

Good luck..