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.

I can confirm with Version: 5.2.0.0.alpha0+; win7

Works in 4.0-> regression

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)

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...

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

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

Adding Cc: to Armin Le Grand

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.

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.

@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

"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.

@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...)"

@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

@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! ;-)

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.

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...

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.

I don't know if the "proposed" commit was ever really committed, anyway the bug persists in version 6.2.

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

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

Added Miklos to cc - I can help if possible, but memories on this from 2014 are not really that fresh anymore...

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.

The bug persists in 24.2.0.1