Bug 113595 - Of multiple STYLE() calls as arguments to IFS() and SWITCH() the first one (last evaluated) is applied.
Summary: Of multiple STYLE() calls as arguments to IFS() and SWITCH() the first one (l...
Status: CLOSED DUPLICATE of bug 111675
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Function
  Show dependency tree / graph
 
Reported: 2017-11-02 11:10 UTC by TBeholder
Modified: 2018-03-12 11:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description TBeholder 2017-11-02 11:10:57 UTC 
Description:
STYLE(...) inside certain functions seems to be called when it should not, even if the rest of the formula seems to work normally.

Steps to Reproduce:
1. Start a new spreadsheet
2. Pick a cell... any cell. Insert this formula: ="foo"&SWITCH( 0,0,3&STYLE("Neutral"),-1,5&STYLE("Bad"),+1,7&STYLE("Good"))
3. Recalculate (F9) a few times.

Actual Results:  
The cell's value is "foo30", toggling between "Bad" and "Good" (red and green) styles.

Expected Results:
The cell shows "foo30" in "Neutral" style (yellow)


Reproducible: Always


User Profile Reset: No



Additional Info:
Without the first (unused) STYLE exactly the same happens. Without either 2nd or 3rd "&STYLE", the cell toggles between the other one and "Neutral" instead.

If the first argument is 1 or -1, the value is picked from the correct branch, and toggling is still between the last 2 styles.

First it looked like SWITCH function is broken, but it's something weirder.

The same happens if you replace SWITCH with CONCATENATE - correct output value, STYLE toggles. But SWITCH is supposed to ignore wrong branches, thus there should be no possibility of racing in GUI or anything like that.

This does not happen with IF:
="foo"&IF( 0=0,3&STYLE("Neutral"), 5&STYLE("Bad"))
The result: "foo30" painted yellow as expected.

Does not depend on whether OpenGL and jRE are enabled or not.
Version: 5.4.1.2
Build ID: 1:5.4.1-0ubuntu1
CPU threads: 2; OS: Linux 4.13; UI render: default; VCL: x11; 
Locale: en-US (en_US.UTF-8); Calc: group


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Comment 1 Buovjaga 2017-11-11 16:35:58 UTC 
Reproduced.

For ; separated style:

="foo"&SWITCH(0;0;3&STYLE("Neutral");-1,5&STYLE("Bad");+1,7&STYLE("Good"))

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: 1aba1955f161cc112dab80b6b3e78ec7761616fc
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 10th 2017
Comment 2 TBeholder 2018-01-03 18:15:59 UTC 
Possibly related to other weird parsing/branching errors in IFS and some other functions - see Bug 111675.
Comment 3 Eike Rathke 2018-03-09 21:43:25 UTC 
IFS() and SWITCH() currently evaluate all parameters' arguments in order encountered from right to left and return the result matching for the condition(s). They do not short-cut evaluation like IF() and CHOOSE() do. Hence for a function that has side effects like STYLE() all styles are applied and the last one wins.
Comment 4 Eike Rathke 2018-03-12 11:15:46 UTC 

*** This bug has been marked as a duplicate of bug 111675 ***