Bug 93185 - Can't change the color of text in table control field of a database form
Summary: Can't change the color of text in table control field of a database form
Status: RESOLVED DUPLICATE of bug 93372
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 93379 99502 (view as bug list)
Depends on:
Blocks: RenderContext
  Show dependency treegraph
 
Reported: 2015-08-06 08:36 UTC by olivier_musson
Modified: 2018-10-08 11:27 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Black background table control problem (112.41 KB, image/jpeg)
2015-08-06 08:36 UTC, olivier_musson
Details
screenshot (15.44 KB, image/png)
2015-08-09 08:21 UTC, Julien Nabet
Details
test file displaying problem (15.19 KB, application/vnd.oasis.opendocument.database)
2015-08-09 10:34 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description olivier_musson 2015-08-06 08:36:11 UTC
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.
Comment 1 Alex Thurgood 2015-08-06 13:06:31 UTC
Confirming

ersion: 5.1.0.0.alpha1+
Build ID: 43ac95ab64980ed958ba144c33971f897791d15f
Locale : fr-FR (fr.UTF-8)

OSX 10.10.4
Comment 2 Alex Thurgood 2015-08-06 14:17:00 UTC
Works fine in 

Version: 4.3.5.2
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
Comment 3 Julien Nabet 2015-08-07 20:26:13 UTC
Could you provide a minimal example file and a step by step process to reproduce this?
Comment 4 olivier_musson 2015-08-08 10:03:31 UTC
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.
Comment 5 Julien Nabet 2015-08-09 08:21:43 UTC
Created attachment 117780 [details]
screenshot

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.
Comment 6 Alex Thurgood 2015-08-09 09:45:09 UTC
(In reply to Julien Nabet from comment #5)

Hi Julien,

> 
> 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.
Comment 7 Julien Nabet 2015-08-09 09:54:25 UTC
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
Comment 8 Alex Thurgood 2015-08-09 10:10:45 UTC
I'll post an existing ODB file that I used to conduct tests with when I'm back at my OSX machine.
Comment 9 Alex Thurgood 2015-08-09 10:32:59 UTC
I have just tried this with:

Version: 5.0.0.5
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.
Comment 10 Alex Thurgood 2015-08-09 10:34:33 UTC
Created attachment 117781 [details]
test file displaying problem
Comment 11 Alex Thurgood 2015-08-09 10:36:52 UTC
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 ;-)
Comment 12 Alex Thurgood 2015-08-09 10:38:46 UTC
If I open the same file and same form in

Version: 4.4.3.2
Build ID: 40m0(Build:2)
Locale : fr_FR

I see yellow text on a black background.
Comment 13 olivier_musson 2015-08-09 10:59:11 UTC
Thanks Alex it's exactly that ... :-)
Comment 14 Julien Nabet 2015-08-09 11:54:42 UTC
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".
Comment 15 Michael Weghorn 2015-08-09 18:22:36 UTC
bibisect result (using the bibisect-50max repository):
 c91580d4bd99f5dd42558a725c9b6449874e13ba is the first bad commit
commit c91580d4bd99f5dd42558a725c9b6449874e13ba
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Wed May 27 23:14:15 2015 +0800

    source-hash-b4bbb5e5d7b31caad2fbcc00382ad27df3c81001
    
    commit b4bbb5e5d7b31caad2fbcc00382ad27df3c81001
    Author:     Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
    AuthorDate: Sun May 17 22:56:46 2015 +0900
    Commit:     Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
    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
          as parameter.
        - 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.
    
        Change-Id: I4ea58461f3b6b08ccfa3e0ddd1a4a3e04f8c4f45

: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?
Comment 16 Alex Thurgood 2015-08-13 06:28:26 UTC
*** Bug 93379 has been marked as a duplicate of this bug. ***
Comment 17 Björn Michaelsen 2015-08-29 08:54:09 UTC
As per comment 15, this seems to be render context related, thus blocking the tracker issue for that.
Comment 18 Tony 2015-09-01 10:35:26 UTC
Hi 
I Can confirm that this issue is still present in 5.0.1.

Cheers

Tony
Comment 19 Tony 2015-09-17 06:31:18 UTC
Hi

Also the issue is still present in 5.0.2 RC1
Comment 20 Tony 2015-09-30 08:51:23 UTC
Hi

I see there have been no updates to this bug, does this mean it won't be fixed?

Thanks

Tony
Comment 21 Julien Nabet 2015-09-30 09:17:37 UTC
(In reply to Tony from comment #20)
> Hi
> 
> I see there have been no updates to this bug, does this mean it won't be
> fixed?
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 :-)
Comment 22 Tony 2015-10-07 11:34:27 UTC
Hi there

Unfortunately my skills, don't include c++ :)
Comment 23 Robinson Tryon (qubit) 2015-12-13 11:13:26 UTC Comment hidden (obsolete)
Comment 24 Tony 2016-01-15 08:55:48 UTC
Hi there

This is still the case in version 5.1.0.1+

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?
Comment 25 Tony 2016-02-29 07:17:34 UTC
Hi there

As of the latest daily build available, Version: 5.1.2.0.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?

Thanks

Tony
Comment 26 Alex Thurgood 2016-04-29 11:37:58 UTC
*** Bug 99502 has been marked as a duplicate of this bug. ***
Comment 27 Xisco Faulí 2016-09-26 15:09:41 UTC
Adding Cc: to Tomaž Vajngerl
Comment 28 Alex Thurgood 2017-08-01 10:49:43 UTC
@Tomaž : I guess reverting the problematic commit is out of the question, given that it touches VCL refactoring ?
Comment 29 Michael Milliman 2018-04-13 15:06:10 UTC
This bug still appears in 6.0.3.2 running under Ubuntu 16.04 LTS.
Comment 30 Drew Jensen 2018-04-15 14:55:57 UTC
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.
Comment 31 Xisco Faulí 2018-10-08 11:27:56 UTC
This is fixed in

Version: 6.2.0.0.alpha0+
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 ***