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.
Confirming ersion: 5.1.0.0.alpha1+ Build ID: 43ac95ab64980ed958ba144c33971f897791d15f Locale : fr-FR (fr.UTF-8) OSX 10.10.4
Works fine in Version: 4.3.5.2 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] 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.
(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.
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: 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.
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 Version: 4.4.3.2 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 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?
*** 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.
Hi I Can confirm that this issue is still present in 5.0.1. Cheers Tony
Hi Also the issue is still present in 5.0.2 RC1
Hi I see there have been no updates to this bug, does this mean it won't be fixed? Thanks Tony
(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 :-)
Hi there Unfortunately my skills, don't include c++ :)
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
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?
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
*** 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 6.0.3.2 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 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 ***