Created attachment 117706 [details]
Black background table control problem
I have many existing table control displaying table data with a black background color for the table control and a cyan 2 font display color. Now none of those table controls are displaying my table data because there is a problem with the font color of table control. It's impossible to change the table control font color. It stays black whatever you define in Font Effect color. I found the problem by turning the background color to white and then I can see all my data like before.
This happen on both Windows and Linux.
As you can see on the attachment picture the other individual field having a black background color correctly display the green color font.
To resume the bug is about the font color which are not changeable anymore only in table control field.
Build ID: 43ac95ab64980ed958ba144c33971f897791d15f
Locale : fr-FR (fr.UTF-8)
Works fine in
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
Could you provide a minimal example file and a step by step process to reproduce this?
To reproduce the problem create a new database. Create a new FORM and insert a control table. In the table control properties choose BLACK background and try to select a font color like blue or green. Then try to display the table data in your FORM and you will see like on the picture I sent you a BLACK background and no data displayed as the default font color stays black whatever color you choose for the font ...
The problem appeared with version 5 on both Windows and Linux.
I haven't had this problem with all the previous 4.X versions on Windows or Linux.
No need to test it with other version than 5.X.
Created attachment 117780 [details]
On pc Debian x86-64 with master sources updated 2 days ago, I tried to reproduce this but didn't reproduce the problem (or perhaps missed it).
I selected black for background and green for font, these colors appear in form when viewing table values.
(In reply to Julien Nabet from comment #5)
> On pc Debian x86-64 with master sources updated 2 days ago, I tried to
> reproduce this but didn't reproduce the problem (or perhaps missed it).
> I selected black for background and green for font, these colors appear in
> form when viewing table values.
Did you try and reproduce this with an existing ODB file, i.e. one made with a previous version of LO, or did you start with a completely new ODB ? Just wondering whether some of the recent configuration changes with regard to background colour settings generally might have had an influence here.
I created a brand new file.
Reading your question, I started again from scratched with LO Debian package 4.4.5 and I don't reproduce the problem too.
Remark: The weird thing is, in both case (4.4.5 + master sources), LO seemed to hang (I didn't wait more than 10 secs) when saving the file at its creation but that's unrelated I suppose
I'll post an existing ODB file that I used to conduct tests with when I'm back at my OSX machine.
I have just tried this with:
Build ID: 437e4abdf9e72fd0a6e6f8697a0e659bc77f9b10
Locale : fr-FR (fr_FR.UTF-8)
on Linux Mint 17.2 Rafaela
and can reproduce the problem, using an ODB file created with an earlier version of LibreOffice.
Created attachment 117781 [details]
test file displaying problem
The test file I uploaded to the bug report contains a grid control in the only form that was created via the wizard.
The grid control has a black background colour and is supposed to show the data in yellow.
As one can see from the form when it is opened, the text remains black, on a black background, therefore invisible ;-)
If I open the same file and same form in
Build ID: 40m0(Build:2)
Locale : fr_FR
I see yellow text on a black background.
Thanks Alex it's exactly that ... :-)
Thank you Alex for your test file.
I could reproduce this from a brand new file.
I hadn't use a table control but just a multiselection.
I found "table control" after having clicked "More controls".
bibisect result (using the bibisect-50max repository):
c91580d4bd99f5dd42558a725c9b6449874e13ba is the first bad commit
Author: Matthew Francis <firstname.lastname@example.org>
Date: Wed May 27 23:14:15 2015 +0800
Author: Tomaž Vajngerl <email@example.com>
AuthorDate: Sun May 17 22:56:46 2015 +0900
Commit: Tomaž Vajngerl <firstname.lastname@example.org>
CommitDate: Mon May 18 11:22:49 2015 +0900
refactor how font, fg. and bg. are applied in widgets/controls
- Move vcl::RenderContext to outdev.
- Change some methods on vcl::Window to accept RenderContext
- Add ApplySettings to vcl::Window - This method is called before
painting. Refactor existing classes that use InitSettings to
have ApplySettings or mark the classes to be refactored later.
- Add RenderSettings for adding defered settings to rendering.
This is similar to ApplySettings but for more ad-hoc calls.
:040000 040000 f9a462284415a152e18e911e9958b2b89135554e 67e888db41932c0f3b56f1058daed6a634d45318 M opt
$ git bisect log
# bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
# good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
git bisect start 'latest' 'oldest'
# good: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
git bisect good 0c30a2c797b249d0cd804cb71554946e2276b557
# good: [2ce02b2ce56f12b9fcb9efbd380596975a3a5686] source-hash-17d714eef491bda2512ba8012e5b3067ca19a5be
git bisect good 2ce02b2ce56f12b9fcb9efbd380596975a3a5686
# good: [40875247f0002056effdf6d2fbe43627691cd86c] source-hash-93f0b14458a618ad575cd446680e5c4aa7d87bdc
git bisect good 40875247f0002056effdf6d2fbe43627691cd86c
# skip: [61f66b1a251477193d796411ca95f50d606ead45] source-hash-3fd5f8919ec2256c70ff26c14cb9f8065c5cb2f1
git bisect skip 61f66b1a251477193d796411ca95f50d606ead45
# good: [e7374cd735af2344dae55be40946d96633d2f6ee] source-hash-8a91528a3e03fe6e2923c33327b687ecf57adb0b
git bisect good e7374cd735af2344dae55be40946d96633d2f6ee
# good: [541837707e7b0c5f5335180de535043c43e78e8d] source-hash-0811de12ee6727bbb9d4265217833ba02301eed8
git bisect good 541837707e7b0c5f5335180de535043c43e78e8d
# bad: [ab7dc1f0829167681894eb9f833d7ab348d91669] source-hash-e27ee95cced755e52b62d6cb095bc911ca3fbbe6
git bisect bad ab7dc1f0829167681894eb9f833d7ab348d91669
# good: [fa6b220d5ca96e8d2cbf8a12980ae4074b7a7fa0] source-hash-9bb59aab72d8226e0d31d71e52125b0a9474a30b
git bisect good fa6b220d5ca96e8d2cbf8a12980ae4074b7a7fa0
# good: [1599f87e48a938167cc328c857b384a383bb44bc] source-hash-a76dcdfaa6c6d2b1d73fb1c96fe38dd7e452f48a
git bisect good 1599f87e48a938167cc328c857b384a383bb44bc
# good: [2e616994f8ae0952d540b22204852af60b37b112] source-hash-598f0e26c16f18b6ea03ef1e0e6d7d9dddf6d10f
git bisect good 2e616994f8ae0952d540b22204852af60b37b112
# good: [5ccfb271f131b7ab936d5ee3a0a85ddd1a4b9262] source-hash-773bb53d0b672fbb6b274e45f35228c9427d7fb4
git bisect good 5ccfb271f131b7ab936d5ee3a0a85ddd1a4b9262
# good: [a9df50d9865d334a08ca9b5043c7b730f131f2b9] source-hash-5862ed1851ecc755aa6c49789e00cd920f6a5036
git bisect good a9df50d9865d334a08ca9b5043c7b730f131f2b9
# good: [a203270d19f0e8d7d57286bbdab960f5604d8126] source-hash-2ca7795a6a723c701f295323fcc3f6c52ad37976
git bisect good a203270d19f0e8d7d57286bbdab960f5604d8126
# bad: [c91580d4bd99f5dd42558a725c9b6449874e13ba] source-hash-b4bbb5e5d7b31caad2fbcc00382ad27df3c81001
git bisect bad c91580d4bd99f5dd42558a725c9b6449874e13ba
# first bad commit: [c91580d4bd99f5dd42558a725c9b6449874e13ba] source-hash-b4bbb5e5d7b31caad2fbcc00382ad27df3c81001
@Tomaž: Could you possibly have a look at this?
*** Bug 93379 has been marked as a duplicate of this bug. ***
As per comment 15, this seems to be render context related, thus blocking the tracker issue for that.
I Can confirm that this issue is still present in 5.0.1.
Also the issue is still present in 5.0.2 RC1
I see there have been no updates to this bug, does this mean it won't be fixed?
(In reply to Tony from comment #20)
> I see there have been no updates to this bug, does this mean it won't be
No, it does mean that devs work on other bugtrackers for the moment. Just be patient or if you know C++, you may give it a try and propose a patch :-)
Unfortunately my skills, don't include c++ :)
Migrating Whiteboard tags to Keywords: (bibisected)
This is still the case in version 220.127.116.11+
Also, I created a new base document, and in that new document, I'm also unable to change the font colour, I'm sure I read somewhere, that this bug didn't exist in newly created Base databases?
As of the latest daily build available, Version: 18.104.22.168.0+, Build ID: d0b16f53d3372d4176ea1a119de8d04f2aa05ad4 this issue still persists.
Unfortunately, this prevent s us from upgrading LO to any version 5. Is there a fix time?
*** Bug 99502 has been marked as a duplicate of this bug. ***
Adding Cc: to Tomaž Vajngerl
@Tomaž : I guess reverting the problematic commit is out of the question, given that it touches VCL refactoring ?
This bug still appears in 22.214.171.124 running under Ubuntu 16.04 LTS.
I tired the test database (attached) with Libo6.1Alpha0 (daily build from the 11th)
The database converts to embedded firebird without any apparent problems.
The form however continues to display w/black background and white text.
This is fixed in
Build ID: 4854acc7929ea58632c5d0f7f80a4adc3c62b8cd
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Closing as a duplicate of bug 93372
*** This bug has been marked as a duplicate of bug 93372 ***