Version: 6.4.4.2 (x64) Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded 1. Open a writer file. 2. Place the cursor in a paragraph and open "Paragraph style > Borders." 3. In the Line arrangement presets, click on "Top and bottom borders", for example. 4. Close the dialogue, then reopen it. EXPECTED RESULT: The "Top and bottom borders" icon should still be selected. ACTUAL RESULT: The selection always returns to "No borders." The same thing happens if you subsequently adjust any other property in the tab. Note: The actual border display is unaffected.
They The "Top and bottom borders" isn't selected, but the lines are still present I have had a similar feeling with columns. IIRC this wasn't the purpose/idea of those buttons. In this case, if you select the bottom line and top line in the picker what should happen? Anyhow adding UX to be certain
Enter some dummy text, change the style to something else but Default (eg. Endnote), change this style and use border on top and bottom with red line color. You should see the paragraph using this style now with lines on top and bottom. Apply some other style to see the border gone. Go to the properties of the modified style and you find the borders as modified, top and bottom on and in red. Works perfectly for me. Have you forgotten a step?
For the version detailed above, I can reproduce the described behaviour every time with any file (inc. a new one). If you open the Borders tab you expect it to display the current border setting for THAT paragraph style: in this case the "Set top and bottom borders icon" should still be highlighted. But, instead, the view always reverts to the "Set no borders icon" when the dialogue is reopened—no matter how you set the borders. AFAIK, this applies to all dialogues with a border style in them.
(In reply to R. Green from comment #3) > For the version detailed above, I can reproduce the described behaviour > every time with any file (inc. a new one). > > If you open the Borders tab you expect it to display the current border > setting for THAT paragraph style: in this case the "Set top and bottom > borders icon" should still be highlighted. But, instead, the view always > reverts to the "Set no borders icon" when the dialogue is reopened—no matter > how you set the borders. > > AFAIK, this applies to all dialogues with a border style in them. "Set no borders icon" when the dialogue is reopened—no matter how you set the borders. Only to confirm: It does indeed :-) Point is more what the 'dialog supposed' to do. It's intended as a quick button to set borders. Not to represent the actual border state, I think. However I do see the confusion.
OK, I see your point now.
(In reply to Telesto from comment #4) > However I do see the confusion. I don't. The border tab shows exactly what is set in the style. I'm afraid we are talking about different functions.
(In reply to Heiko Tietze from comment #6) > (In reply to Telesto from comment #4) > > However I do see the confusion. > > I don't. The border tab shows exactly what is set in the style. I'm afraid > we are talking about different functions. Nope, we there are Line Arrangement 'presets'. If you click one, the 'user defined' area is filled with proper borders. If you close the dialog and reopen, the selected 'preset' is gone (set back to "No borders", while the 'user defined' area is showing borders (as expected) The whole point is preset "No borders: being selected with a border (it's only small detail :-)
Now I got it. The five preset options are not enabled automatically when the configuration of borders is defined accordingly (taking the issue another way around). Do we really need this?
(In reply to Heiko Tietze from comment #8) > Now I got it. The five preset options are not enabled automatically when the > configuration of borders is defined accordingly (taking the issue another > way around). Do we really need this? Ideally, yes. It would fit the "Shadow Style" behavior. And the bug report didn't come out of nowhere. But if you start this, you need to change Format -> Columns too. However, looking at implantation costs/ advantages and risks (of some kind of issue).. I tend to not change anything at least not in the short of medium term. So maximum an enhancement request for time the bug tracker being empty; and Developers being disparate for work. However there are still no clear rules related to this. Keeping it open ('bloating' bug tracker) or closing as this won't happen anytime soon. I'm currently more the type of keeping stuff around, instead of closing. As I'm currently reporting anchoring stuff, which more or less occurrences of the same thing in different constellations (to be used for testing if the time comes someone wants to work on it]; but are trivial in the sense of awareness of the issue (it's already now) and doesn't adds nothing 'new'; except having demo's of the problem.
I support the idea to be consistent with other dialogs, but I also think, importance is trivial
(In reply to Dieter from comment #10) > I support the idea to be consistent with other dialogs, but I also think, > importance is trivial Let's do it. We should also enable the respective preset if a combination of border lines is configured respectively.