Description: Bad : Tabelle.getCellbyPosition(6,l).CellBackcolor = &H00FF00 Good: Tabelle.getCellbyPosition(6,l).CellBackcolor = &H01FF01 colorizing backcolor into green fails - the backcolor is changed to white instead if i change the value to &H01FF01 it colorize to green fine Steps to Reproduce: see description Actual Results: &H00ff00 is wrong interpretet to white Expected Results: change cell background to green Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: de Module: SpreadsheetDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: no expected with 7.0.2 with same result - update to 7.1.3.2 with same result
Repro Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Being not a programmer, but conversion of &H00FF00 into a decimal seems to result in -256.
Repro with: Sub TestFunction() ThisComponent.Sheets(0).getCellByPosition(0, 0).CellBackcolor = &H00FF00 End Sub Cell background color should be green in both cases.
As a workaround you may use: ThisComponent.Sheets(0).getCellByPosition(0, 0).CellBackcolor = RGB(0, 255, 0)
So I checked for the exact reason of this bug. In Bug 130476, we changed the behaviour of the hex literals. So in &H00FF00 preceeding zeros are ignored and the resulting number is converted to an int, which leads to -256, which is obviously not a color. However, if you cast the literal to a long by adding & at the end (&H00FF00&), the value is preserved as long and the cell color gets the correct value. So imho not a bug. You can just change your lines from: Tabelle.getCellbyPosition(6,l).CellBackcolor = &H00FF00 to: Tabelle.getCellbyPosition(6,l).CellBackcolor = &H00FF00&