Bug 110458 - EDITING: Labels in Forms couldn't be centered any more
Summary: EDITING: Labels in Forms couldn't be centered any more
Status: RESOLVED DUPLICATE of bug 109242
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2017-07-31 13:53 UTC by Robert Großkopf
Modified: 2017-08-05 17:18 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Change the align of the label in the form to left and afterwords back to centered ... (11.20 KB, application/vnd.oasis.opendocument.database)
2017-07-31 13:53 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2017-07-31 13:53:09 UTC
Created attachment 135020 [details]
Change the align of the label in the form to left and afterwords back to centered ...

Use LO 5.4.0.3 for this test.

Open the form of the attached database. You could see two textfields and two labels above. The labels are centered.

Now open the form for editing, not for input data. Change the first label and set it to left align.
1. Bug: Second label also changes to left align.

Save the form, reopen for input data.
Both labels are set to left align.

Open the form again for editing. Set the labels back to centered. Save, close, reopen. 
2. Bug: Labels aren't centered.
With LO 5.4.0.3 it's impossible to center the text in label-fields. Haven't tested if its the same of other fields ...

Tested with
Version: 5.4.0.3
Build-ID: 92c2794a7c181ba4c1c5053618179937228ed1fb
CPU-Threads: 4; Betriebssystem:Linux 4.4; UI-Render: Standard; VCL: kde4; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

Works with 5.3.5.1 on the same machine, SUSE  42.2 64bit rpm Linux.
Comment 1 Jochen 2017-07-31 14:03:54 UTC
I can reproduce this bug (OS Windows 10)
Comment 2 Harald Berger 2017-07-31 14:37:49 UTC
confirmed
Comment 3 Alex Thurgood 2017-07-31 15:40:31 UTC
Confirming with

Version: 5.4.0.3
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Comment 4 Regina Henschel 2017-07-31 15:47:07 UTC
The form controls have some identical automatic styles. That should not happen, because "automatic styles" describe properties of a single object. How do you have created the document? Do you insert each control by using the toolbar? Or do you copy&paste them? Or something else?
Comment 5 Alex Thurgood 2017-07-31 15:48:00 UTC
Also reproduced on master

Version: 6.0.0.0.alpha0+
Build ID: 376e27dd498d64212e570354a94c527b37d367b1
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Comment 6 Robert Großkopf 2017-07-31 18:53:35 UTC
(In reply to Regina Henschel from comment #4)
> The form controls have some identical automatic styles. That should not
> happen, because "automatic styles" describe properties of a single object.
> How do you have created the document? Do you insert each control by using
> the toolbar? Or do you copy&paste them? Or something else?

Have added them by the toolbar "Add field".
Afterwords I changed the vertical alignment of both label-fields.
Comment 7 Gerhard Weydt 2017-07-31 22:02:12 UTC
Bug 109177 describes a similar problem, namely that setting a vertical orientation for a scrollbar in design mode is not recognized. It has been already pointed out that setting the vertical orientation by macro works, though.
So you should test if you could set the center alignment by macro, the result would narrow down the scope of possible reasons.

Gerhard
Comment 8 Alex Thurgood 2017-08-01 08:20:43 UTC
(In reply to Regina Henschel from comment #4)
> The form controls have some identical automatic styles. That should not
> happen, because "automatic styles" describe properties of a single object.
> How do you have created the document? Do you insert each control by using
> the toolbar? Or do you copy&paste them? Or something else?

@Regina :
not by any chance related to the changes recently made here ?

https://gerrit.libreoffice.org/#/c/38861/4/sw/source/core/unocore/unostyle.cxx
Comment 9 Regina Henschel 2017-08-01 10:41:26 UTC
I do not get the error with Version: 6.0.0.0.alpha0+
Build ID: 0163984ce76141665296969118791a9ffbf076eb
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-30_23:34:14
Locale: de-DE (de_DE); Calc: group

@ Alex Thurgood : I have no idea. Testing with older versions shows, that using automatic styles has always been this way, so likely it is not related.
Can you test with a newer version from master, whether you still get the error?
Comment 10 Alex Thurgood 2017-08-03 16:16:26 UTC
(In reply to Regina Henschel from comment #9)
> I do not get the error with Version: 6.0.0.0.alpha0+
> Build ID: 0163984ce76141665296969118791a9ffbf076eb
> CPU threads: 4; OS: Windows 6.1; UI render: default; 
> TinderBox: Win-x86@42, Branch:master, Time: 2017-07-30_23:34:14
> Locale: de-DE (de_DE); Calc: group
> 
> @ Alex Thurgood : I have no idea. Testing with older versions shows, that
> using automatic styles has always been this way, so likely it is not related.
> Can you test with a newer version from master, whether you still get the
> error?

@Regina : this is possibly a duplicate of bug 109242
Comment 11 Alex Thurgood 2017-08-03 16:17:15 UTC
(In reply to Alex Thurgood from comment #10)


> 
> @Regina : this is possibly a duplicate of bug 109242

Which is hopefully fixed by Noel in master since 27/07/2017.
Comment 12 Xisco Faulí 2017-08-03 16:21:35 UTC
Not reproducible in

Version: 6.0.0.0.alpha0+
Build ID: 3f16306964d5bb81dda3c681bcabbacadf424e7b
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

*** This bug has been marked as a duplicate of bug 109242 ***
Comment 13 Xavier Van Wijmeersch 2017-08-04 08:14:04 UTC
But with kde4 the is still there

Version: 6.0.0.0.alpha0+
Build ID: 3dcf6dfceee58360501396390d78c006351aef47
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group
build 20170803
Comment 14 Julien Nabet 2017-08-05 16:32:43 UTC
On pc Debian x86-64 with master sources updated today, I don't reproduce this gtk3 or with kde4 rendering.
However, when wanting to test and put left alignment, I noticed that the 2 fields have the "alignment" value at empty.
Comment 15 Robert Großkopf 2017-08-05 17:14:26 UTC
(In reply to Julien Nabet from comment #14)
> On pc Debian x86-64 with master sources updated today, I don't reproduce
> this gtk3 or with kde4 rendering.
> However, when wanting to test and put left alignment, I noticed that the 2
> fields have the "alignment" value at empty.

Hi Julien,

where do you get the master?
I 'm looking here, but it all seems to be empty:
http://dev-builds.libreoffice.org/daily/master/
Comment 16 Julien Nabet 2017-08-05 17:18:46 UTC
(In reply to robert from comment #15)
>...
> where do you get the master?
> I 'm looking here, but it all seems to be empty:
> http://dev-builds.libreoffice.org/daily/master/

Sorry Robert, I build LO from sources retrieved from git.
There are indeed almost only empty directories in daily builds.
I only noticed this one:
http://dev-builds.libreoffice.org/daily/master/Linux-archive-x86_64%4080-updater/current/