Bug 99125 - Property ParaBackColor in Writer can no longer be set via Uno command
Summary: Property ParaBackColor in Writer can no longer be set via Uno command
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
4.4.6.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-DrawingLayer-FillStyles
  Show dependency treegraph
 
Reported: 2016-04-06 16:30 UTC by Gerhard Weydt
Modified: 2024-01-08 18:20 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
3 macros to show the result of background color change (71.06 KB, application/vnd.oasis.opendocument.text)
2016-04-08 16:36 UTC, Bernard Marcelly
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Weydt 2016-04-06 16:30:51 UTC
Since at least release 4.4.6 the property ParaBackColor in Writer cannot be set.
A simple test: in a writer document with at least one paragraph execute the code:

Sub Main
firstParagraph = Thiscomponent.text.createEnumeration.nextElement
firstParagraph.setPropertyValue("ParaBackColor", RGB(39,0,119))
'	or:	firstParagraph.ParaBackColor = RGB(39,0,119)
msgbox firstParagraph.ParaBackColor
End Sub

The results are:
- in the document the paragraph is coloured
- the msgbox returns -1
- after saving, closing and reopening the document the colour is no longer visible, consistent with the msgbox return.

This worked in older versions of LibreOffice and still works in Apache OpenOffice 4.1.2.
It still does not work in LO 5.1.1.
Similar settings for CharColor and CharBackColor do work as usual (but these operate on a lower enumeration level).
Comment 1 Bernard Marcelly 2016-04-08 16:36:23 UTC
Created attachment 124190 [details]
3 macros to show the result of background color change

This attachment contains macros that change the background color from a cursor, and from a paragraph. Also a macro that displays the current values of some properties.

I have run them on Apache OpenOffice 4.1.1 and on LibreOffice 5.0.5.
Screenshots in the document show that LibreOffice behaves differently from Apache OpenOffice.

You can see that Apache OpenOffice gives the same result when changing Background color from the cursor, from the paragraph, or from the user interface (manual formatting).

With LibreOffice it is not possible to change the background color of the paragraph by API.
The manual formatting result also differs from Apache OpenOffice.
Comment 2 raal 2016-04-11 12:57:51 UTC
I can confirm with Version: 5.2.0.0.alpha0+; win7

Works in 4.0-> regression
Comment 3 raal 2016-04-11 15:36:49 UTC
Bisected macro ColorByCursor, in msgbox line para1.ParaBackColor = 16776960

This seems to have begun at the below commit.
Adding Cc: to Armin ; Could you possibly take a look at this one?
Thanks
 e642812606be49244f2f775e90169fbd1be29a97 is the first bad commit
commit e642812606be49244f2f775e90169fbd1be29a97
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sat Mar 14 22:28:59 2015 +0800

    source-hash-7d9bb549d498d6beed2c4050c402d09643febdfa
    
    commit 7d9bb549d498d6beed2c4050c402d09643febdfa
    Author:     Armin Le Grand <alg@apache.org>
    AuthorDate: Mon Jun 2 15:00:50 2014 +0000
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Tue Jul 1 13:30:09 2014 +0200
    
        Related: #i124638# Second step of DrawingLayer FillAttributes...
    
        for Writer objects, now added support for Paragraph and PageStyle (including
        Header and Footer) for direct attributes and style attributes
    
        (cherry picked from commit cc25c58f7052827bfebdc9fbeec668c8fa29ed1b)
Comment 4 Armin Le Grand 2016-04-14 07:59:18 UTC
Looks like from Basic the cursor is used to transport attributes, it might be that at cursor the needed set of attributes for FillStyle is missing. OS is on cc already...
Comment 5 Volga 2016-07-19 04:34:56 UTC
This bug cause the background colour feature has been banned in DCM extension.

http://extensions.libreoffice.org/extension-center/dcm-direct-colour-management/releases/1.1.2
Comment 6 Gerhard Weydt 2016-07-23 16:35:00 UTC
Hello General Kutuzov,

I'am sorry to have to contradict you. I am the author of DCM, and I discovered and reported the bug when I tested the new version of LibreOffice. DCM needs to use exactly the statement which doesn't work in the newer releases of LibreOffice, so DCM cannot be used to circumvent ist. I have therefore blocked the relevant button in DCM, with a text explaining the reason.
If you use an older version of DCM where the feature isn't blocked, it seems that DCM does change the colour, but this is not saved in the document, so the change is lost when you open the document again, later on.

Gerhard
Comment 7 Xisco Faulí 2016-09-26 15:03:10 UTC
Adding Cc: to Armin Le Grand
Comment 8 Gerhard Weydt 2017-04-04 16:52:47 UTC
Reading comment #5 again I think I misunderstood Volga for my answer in #6.
Now I think he wanted to say that this bug caused me to ban the feature to deactivate changing the paragraph background colour in DCM.
Comment 9 Gerhard Weydt 2017-04-04 16:56:40 UTC
One year has passed by since the bug was reported, and no one seems to have been working on it.
Changing the paragraph background colour is in my opinion a useful feature for creating reports, if you don't use the Report Builder, and also for other documents created automatically from other sources.
Comment 10 Butch 2017-05-13 12:59:32 UTC
@Gerhard Weydt: After two days of desperate and useless occupation with this problem I finally discovered this bug report... 

Here a detailed description of my experience with a macro using ParaBackColor. There are a few aspects not mentioned here so far.

1) After applying the macro on a selection (e.g. one ore two paragraphs) the background color is changed apparently as desired.
(2) However, if I open the paragraph format dialog > Area (with the cursor in one of the involved paragraphs), the activated option is None!
(3) If I do the same change manually, the activated option is Color, and the New field shows the new color (completely as expected).
(4) If I save the file as odt or fodt, the color change made by macro is lost.
(5) If I save the file as doc, and open this doc, the new background color is shown, but the result is as described in (2). Not only for a paragraph changed by macro, but also for a paragraph changed manually!!! If I save the file again as doc, this behavior continues. If I save it as odt, both changes are lost.
(6) In rtf the background color is preserved correctly (in both cases, macro/manually). (The only difference is that the text is not displayed white on red but black on red.)

Gerhard, do you know a workaround to change the paragraph background color by a macro using another method?

Butch
Comment 11 Tibor Kovács 2017-05-14 08:37:32 UTC
"Gerhard, do you know a workaround to change the paragraph background color by a macro using another method?"

There an another way: by using the paragraph styles. You can create, apply and modify them by a macro or manually, ant it works fine.
Comment 12 Butch 2017-05-14 10:25:54 UTC
@Gerhard: Thank you! Unfortunatelly beyond my macro coding capabilities...


A comment from another forum, by Zizi64:
"It is not a bug of the LO Basic (StarBasic), because the embedded Basic is a very simple programming language and IDE, with a few commands only.
You can try it: Just use the related API functions with an another supported programming language.

My opinion: The bug is located in the API functions of the LO, and in the handler of the API functions. The changed state is appeared on the sreen, but it is no stored into the document archive (or there is a bug/mistake in the storaging procedure...)"
Comment 13 Gerhard Weydt 2017-05-14 14:03:43 UTC
@Butch: Comment #11 is not by me, but by Tibor Kovacs, and I am sure it would work the way he proposes. I didn't try to write the code yet, but setting the color for a style sets the value in ParaBackColor, in contrast with the paragraph properties, where it is not set.

It should be something like:
dim neu as object
neu = ThisComponent.createInstance("com.sun.star.style.ParagraphStyle")
ThisComponent.StyleFamilies.getByName("ParagraphStyles").insertByName("?newName?",neu)
neu.ParaBackColor = RGB(0, 255, 0)

and you would have to set some other attributes as well. And then you would have to set ParaStyleName = "?newName?" for the paragraph(s) you want to color.

But there is another way: using the dispatcher (which I normally do not use). I recorded a macro when setting the background color via the sidebar, and here is what was created:

rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "BackgroundColor"
args1(0).Value = 52428

dispatcher.executeDispatch(document, ".uno:BackgroundColor", "", 0, args1())

The color 52428 is the internal value, you would probably use the function RGB to calculate the value.

This does also work für multiple selections, with the exemption that paragraphs are not changed if the selection element contained in this pargraph has length zero, unless the entire selection consists only of one string of length zero.

Using the macro recorder, by the way, does not work correctly when setting the color using the menu: the macro created concerns numbering! That's probably one of the reasons why macro recording is considered experimental.

Gerhard
Comment 14 Butch 2017-05-16 05:37:00 UTC
@Gerhard: Thank you for your workaround (you saved my life ;-)) and even more for the hint how to extend the usability of macro recording!

@Armin Le Grand: The time has come to eliminate this bug! ;-)
Comment 15 Gerhard Weydt 2017-06-16 22:11:10 UTC
In comment #11 Tibor kovács suggested another way to set the paragraph background colour, via a paragraph style. I have used this (already sketched in comment 13) now in my extension DCM, where changing background colour was temporarily disabled because of this bug. Many thanks to Tibor, Butch will certainly agree, see comment #14.
The workaround is using two crutches, namely creating a style and then undoing ist, and setting the background colour via the dispatcher, so the urgency of working on the bug is not decreased by it!
I therefore - and because of the statement cited in comment #12, with which I totally agree and am sorry that I didn't find the right word then - changed the title to a more general meaning.
Comment 16 Justin L 2018-11-29 06:33:27 UTC
I think that setting background color via macro now requires two UNO variables.  
para1.FillStyle = 1 ' FillStyle_SOLID
para1.FillColor = RGB(255,255,0) ' yellow

However, that didn't work for the cursor...
Comment 17 Justin L 2018-11-29 11:46:14 UTC
The cursor wasn't able to see the "new" FillProperties. That is "fixed" by proposed commit https://gerrit.libreoffice.org/64226

Whether that is the correct way to do it remains to be seen - this isn't my normal area of hacking. But this should at least give a head-start towards fully resolving this bug.
Comment 18 Gerhard Weydt 2019-06-09 23:26:57 UTC
I don't know if the "proposed" commit was ever really committed, anyway the bug persists in version 6.2.
Comment 19 QA Administrators 2021-06-09 03:48:07 UTC Comment hidden (obsolete)
Comment 20 Gerhard Weydt 2021-06-13 18:53:53 UTC
The bug is still present in
Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 93a3e2f86c27b06062708fe788963a0e49f3a90b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
Comment 21 Armin Le Grand 2021-06-21 09:21:46 UTC
This is a feature from 2014 which I did on Apache AOO, and as noted in the Description, it works there flawlessly.
I did not decide to integrate it to LO nor did I do it, so I do not see this as 'my' regression. I guess the person who did integrate it to LO is/was responsible for making sure it works as designed *before* using it resp. fix stuff accordingly and has to stand in for regressions/f'up-s from my POV
Comment 22 Armin Le Grand 2021-06-21 09:24:38 UTC
Added Miklos to cc - I can help if possible, but memories on this from 2014 are not really that fresh anymore...
Comment 23 Armin Le Grand 2022-01-05 09:50:56 UTC
This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.
Comment 24 QA Administrators 2024-01-06 03:13:48 UTC Comment hidden (obsolete)
Comment 25 Gerhard Weydt 2024-01-08 18:20:47 UTC
The bug persists in 24.2.0.1