[Solved] Changing paragraph background color by macro

[Butch1]

Hi!

Does somebody here know how to change the background color of a selected paragraph by macro (with exactly the same effect as manually)?

Thank you in advance!
B.

PS:
I was testing a macro using (e.g.)
oSel.ParaBackColor = rgb(100,0,0)
which changes the backround "apparently" (the change is lost when the file is saved!).
So ParaBackColor seems not to be the right way. EDITED: A bug in LO (see below). Another simple solution: see below.

[John_Ha]

Swith on Record macro. Do the manual change. Stop recording and save the macro.

See the tutorial on recording macros or check the manual.

[Butch1]

@John_Ha: No no no, macro recording does not record such formattings!

EDITED: But there could be a way to record it! See below!

[Zizi64]

Use (create and apply) your own paragraph styles instead of the manual (direct) formatting.

[Butch1]

@Zizi64: In my case unfortunately this is not an option, I have to find a macro solution.

[Zizi64]

You can create, (apply), and modify the Styles by macro.

[Butch1]

@Zizi64: Thank you for your 'workaround' solutions, but this background-color changing in my case is a part of a large conversion macro. Creating new styles etc. inside this macro would be a too extravagant detour. At least at the moment I suppose that there must be a direct and simple way as for many other paragraph properties ...

[Zizi64]

direct and simple way

The 'direct' way is not a 'simple' way. The 'direct' way is not a 'better' way...

The 'Style's feature is the most valuable feature of the opensource office suites (AOO and LO).


Do you want edit the background properties all of paragraphs in a specific document? Or the selected ones only? How you will get the paragraphs (directly) for changing theirs properties?

[Butch1]

@Zizi64: Ok ok, but all this are theoretical questions which would be of relevance if there is no direct and simple way, and which say nothing about existence of such a way! For instance, there is a direct and simple way to change other paragraph properties like margins ... here the direct way would be the most simple way (for my purposes). Here a simple macro which directly changes the left margin of all paragraphs in the selection:

Code: Select all

Sub Indent

dim document   as object
dim dispatcher as object

document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

dim args1(1) as new com.sun.star.beans.PropertyValue
args1(0).Name = "LeftRightMargin.LeftMargin"
args1(0).Value = 6110
args1(1).Name = "LeftRightMargin.TextLeftMargin"
args1(1).Value = 6110

dispatcher.executeDispatch(document, ".uno:LeftRightMargin", "", 0, args1())
End Sub

[Zizi64]

OK, it is your job. You will work on more than necessary...

[Hagar Delest]

I tried your macro and it works fine on my AOO 4.1.3 with the following code (saving as .odt or even .doc):

Code: Select all

Sub Para_Color
Dim sSelection as string	'Selected text
Dim oDoc as object			'Points to the current document

oDoc = ThisComponent
oSel = oDoc.CurrentSelection

'  Pick up the text selected.
oSel = oDoc.getCurrentSelection().getByIndex(0)
oSel.ParaBackColor = RGB(100, 0, 0)

End sub

You can also limit the application to the selection with CharBackColor instead of ParaBackColor.

Please add [Solved] at the beginning of the title in your first post (top of the topic) with the edit button if your issue has been fixed.

[Butch1]

I tried your macro and it works fine on my AOO 4.1.3 with the following code (saving as .odt or even .doc)

Thank you very much, Hagar! Your information changes my question to a misterious one. If you save the file (after using the macro) as odt, the new background color is not lost? I am using LO 5.3.2.2 (Portable), and the new background color is lost in odt or fodt (however, I see now that it is preserved in doc). If this is so, there could be a LO bug involved.

Here is my detailed description of my observations. I used the ParaBackColor method in different manners in my macros, allways with the same result. The macro from your posting leads to the same result too.

(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.
ADDED:
(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.)

Could you confirm that your AOO shows none of these misterious things?

Thanks again,
Butch

[Hagar Delest]

If you save the file (after using the macro) as odt, the new background color is not lost?

Correct.

(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!

I did exactly what you described: ran the macro, saved (in .odt), closed and opened the file. The background is still there, both in the paragraph dialog and in the Sidebar:

[Butch1]

@Hagar: Thank you very much!!! Your information leads to the conclusion that all my problems are caused by a bug in LO.

Is here somebody who could test the macro in a LO version?

Butch

[Butch1]

I know now definitely there is a ParaBackColor bug in LO.
https://bugs.documentfoundation.org/sho ... i?id=99125
Sorry!

[Zizi64]

Is here somebody who could test the macro in a LO version?

This task is achievable with paragraph styles. And this 'style method' works in AOO and LO.
Create (manually or by a macro) a new paragraph style based on the Default paragraph style (or based on an another one, as you want it). Set the background color of the custom paragraph style. You can apply the custom paragraph style to the selected text:

Code: Select all

oSel.ParaStyleName = "MyParaColorBkG_1"

(instead of the oSel.ParaBackColor = RGB(100, 0, 0)
(The other API functions and commands are same as the code snippet above.)


A similar topic:
viewtopic.php?f=20&t=53581

[Butch1]

@Zizi64: Thank you very much, Zizi, but, again, I cannot use this indirect, detour way in my case. The documents where I have to apply the macro are not only my own documents, and they contain direct formatting inside paragraphs (e.g. font color ...). (Btw: What is your working method when writing a text? If you need a word in bold, or in a specific font color, you always use styles instead of direct formatting?) Applying a paragraph style to such paragraphs would lead to the lost of such formatting. Or am I wrong?

[Zizi64]

Applying a paragraph style to such paragraphs would lead to the lost of such formatting. Or am I wrong?

You can structurize the applied paragraph styles. And you can get (read) by the name of the originally applied style of the paragraph.

Then you can:
- modify the properties of the applied style by a macro, (for example the background color of the style) or
- apply an another /"child"/ paragraph conditionally based on the applied paragraph style to the selected paragraph.

[Zizi64]

It is better (best!) to apply ALL of the properties of the textual documents by Styles: Character styles, paragraph styles, page styles, etc...

[Hagar Delest]

If you need a word in bold, or in a specific font color, you always use styles instead of direct formatting?

Personally, I don't always use styles. For characteristics like bold, italics and underline for small strings, I use direct formatting. I use styles for strings that may need to be changed all at once in the document in the future.

Applying a paragraph style to such paragraphs would lead to the lost of such formatting.

Not at all. The direct formatting or character style is kept as long as you don't clear the formatting (Ctrl+M).

See also that topic, it may help understand the power of the styles: [Solved] Taking note and tagging format.

[Butch1]

Not at all. The direct formatting or character style is kept as long as you don't clear the formatting (Ctrl+M).

Ok, I see, of course. I have led my argument in a wrong direction. My whole problem is that the documents which I want to edit came from very different authors and sources and are converted to odt. I have no influence on how the formatting is done in this documents, and the most formatting is direct, also paragraph formatting. There are e.g. indented paragraphs etc., all in direct formatting, which would be lost when applying a new paragraph style (I suppose here I am right?). In this situation the whole OO/LO styles philosophy is not applicable ... The simplest 3- or 4-lines macro setting ParaBackColor would be a perfect solution for my purposes. But unfortunatelly there is this stupid bug in LO Basic...

But, if I would be forced to found a complicated workaround (and to accept losts of direct paragraph formatting):

You can structurize the applied paragraph styles...

I see that in the books from Pitonyak there are some elements which I probably could use to make something like this (identify the paragraph style and its properties for each paragraph in the selection, create a new style with changed background, apply it to the paragraph). But I guess this whole task is beyond my capabilities...

Thanks for all your contributions!!!

[Zizi64]

My whole problem is that the documents which I want to edit came from very different authors and sources and are converted to odt.

In this case you MUST use the styles (manually or by macro). There is not easier, or better way for this task.

But unfortunatelly there is this stupid bug in LO Basic...

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

[erbsenzahl]

Crossposting: http://de.openoffice.info/viewtopic.php?f=18&t=68178

The last 2 replies in the German forum state:

• The issue does not work since LO 4.1.2 (komma4)
• It is an unsolved bug, see https://bugs.documentfoundation.org/sho ... i?id=99125 (Toxitom)

[Butch1]

In this case you MUST use the styles (manually or by macro). There is not easier, or better way for this task.

Ok, Zizi64, I really understand the benefits of the styles in OO/LO. But what I really don't understand is where comes this strict and unyielding insisting to do every thing in every situation by styles! If I have a document which should be edited or layout-improved fastly for a specific singular purpose, e.g. to be outputed to pdf, and I never again will have to do with this document, why for God's sake this work MUST be done by styles, at least if there is an easy option of direct formatting? Why???

In my case there is an extremely easy option in this situation and for my purpose: a simple macro doing direct formatting. If there wouldn't be the stupid bug, this would work perfectly for my purpose, and would be incomparably easier than every other way involving styles.

To leave this philosophical aspects: In the meantime I found a workaround, another simple macro method not using the buggy ParaBackColor:

Code: Select all

sub ParaBackground
dim document   as object
dim dispatcher as object
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
dim args1(0) as new com.sun.star.beans.PropertyValue
args1(0).Name = "BackgroundColor"
args1(0).Value = 13290444
dispatcher.executeDispatch(document, ".uno:BackgroundColor", "", 0, args1())
dispatcher.executeDispatch(document, ".uno:Escape", "", 0, Array())
end sub

The hint comes from Gerhard Weydt. Maybe even more important is his hint that such a macro can be created by macro recording! I don't know if this problem exists in OO too (does it?), but in LO macro recording fails in this case (as in many other cases). Gerhard Weydt discovered that this happens only if the menu (> Paragraph ...) is used, but not if the formatting is done via Sidebar!!! Isn't this great!?

EDITED: I will change the question status to Solved. Thanks to Gerhard Weydt!!!

[Zizi64]

In my case there is an extremely easy option in this situation and for my purpose: a simple macro doing direct formatting. If there wouldn't be the stupid bug, this would work perfectly for my purpose, and would be incomparably easier than every other way involving styles.

The Styles are nothing more than 'grouped properties' (of the paragraphs; of the pages; of the characters, etc...) with a specific name.
When you apply a style (by double click on the style name), actually you launch a MACRO (a peredefined macro), what will apply the desired (grouped) properties based on the style names.

Maybe even more important is his hint that such a macro can be created by macro recording! I don't know if this problem exists in OO too (does it?), but in LO macro recording fails in this case (as in many other cases). Gerhard Weydt discovered that this happens only if the menu (> Paragraph ...) is used, but not if the formatting is done via Sidebar!!! Isn't this great!?

The macro recorder (of the AOO and of the LO) has a very limited capability. It can not record every user's activity. It works mostly only with the Menu items.
It is better to WRITE the macros based on the API functions, but not RECORD them. The macro recorder was developed for the beginners, who want a solution that is similar to MS-office.

[Butch1]

@Zizi64: You are incorrigible, aren't you?! Are you a professor or so?

[Zizi64]

Are you a professor or so?

No, I am not.
I am a USER only, like you; but I try to use those functions/features of the AOO/LO, that make my life easier...


And if I want to control the Office Suite by macro program code, then I always WRITE my macros, but I not record them. When I was a beginner, I recorded my macros too... But I studied the API functions, and the code snippets on this forum, and Andrew Pitonyak's books: and now I can write my macros. This way is much more efficient than the "recording way".

[Butch1]

And if I want to control the Office Suite by macro program code, then I always WRITE my macros, but I not record them. When I was a beginner, I recorded my macros too... But I studied the API functions, and the code snippets on this forum, and Andrew Pitonyak's books: and now I can write my macros. This way is much more efficient than the "recording way".

A friendly feedback from another user--please try to read it as being meant sincerely friendly: Yes, of course, this is exactly the right way for users who want to work really professionally with OO/LO and to use all potentials of it. Of course. But all your answers are strictly ignoring that there could be another kind of users which want to use the Suite on a lower level of investments (of time...). All your answers say strictly: This is not the right way. But it is the right way for such type uf users!!!!! If I explain how limited is the task I want to do simply by direct formatting, you are forced to explain what styles are. If I am happy to learn that there is a simple method which extends the usability of macro recording, you are forced to explain: "It is better to WRITE the macros based on the API functions, but not RECORD them." But there is a type of users which can benefit of such a method, and this is fully legitimate. You however, at least in this discussion, are strictly ignoring my level of OO/LO usage and my limited tasks to be done, and you are answering continuously questions which I don't have. My working area has nothing to do with office suites, but I am able to use them on a level where the benefit and the investment are balanced. If I have to find a specific nontrivial solution, I am able to search for hints in web or to consult Pitonyak, and to write even complex macros, but I want to do this only if the time investments is in relation to the benefit. And there are many other users which are working on such a level... Even in this fully transparent discussion here: There was my simple question, I explained repeatedly how limited the purpose of the solution is which I am searching for, I showed that there is a simple solution which is not working only due to a stupid bug in the Suite, and I finally presented another simple but working solution---but still all your answers signalize: No, this is not the right way...

[Zizi64]

All your answers say strictly: This is not the right way.

Yes, and it is a true fact.
And it is a fact (unfortunatelly): the direct formatting API method is bugous, and the Style-method works.

The direct formatting is a bad MS Office heritage, and makes it unstructured the documents.

The direct formatting never will be such efficient as efficient the usage of the styles.
The direct formatting - applied by macros is quasi equivalent (seems equivalent) with the styles (for a beginner user). But when you want to reedit a direct formatted document in the future, then you will waste much more time - relative to the applying of the styles way...

...Sorry, my english is very poor...

[Butch1]

@Zizi64:
A boy and his father are going through the desert. The child is dying of thirst. Suddenly they are standing in front of a box with cola bottles. The child wants to grab a bottle, but the father puts the bottle back into the box: "Cola is unhealthy!" From the sky comes a voice: "But your child will die!" And the father answers: "But cola is unhealthy!!!"

Thanks for all contributions. I will change the question status to Solved (by the solution mentioned above, posted by Gerhard Weydt in another forum).