When a drawing has a custom fill color (one that is not in the pallet), and you open it's Area properties window, the Area tab shows the right color, but when you then go to the Color tab, RGB is set to 0 0 0 and showing black color. Doing the same with a drawing that has a fill color that is in the pallet, the Color tab will show the right values. This bug is a bit of a downy because, if you don't know the original RGB values, it prevents to pick up the custom color and put it in the pallet. Bart.
not reproducible with LO 3.6.4.3. (Win7 Home, 64bit)
I think I also can not reproduce this behavior using Linux Mint 15 x64 with LibreOffice 4.0.3.3. @bug reporter: is it possible to attach a sample document which we can reproduce this behavior. Thanks in advance, Joren
No feedback since 6 months, I put it as WFM following Joren's comment.
Bug still there in LibreOffice 4.0.3.3 (on Xubuntu) To reproduce: - In Writer, add a rectangle - click right on it and choose Area in the context menu - goto tab Colors, type a bogus name and change the RGB values - click OK - if a message says the color ain't saved, choose Add - click right on the rectangle, choose Area and goto tab Colors - if you saved the color - click Delete and then OK (now the color is not in the pallet anymore) - click right on the rectangle, choose Area and goto tab Colors - check the RGB values, they are set to 0 0 0 (showing black color) I added a sample document with a rectangle. It has it's area filled with a color named 'test' and R=123, G=213, B=123. Sorry I missed comments 1 and 2. I hope someone still will try to solve this little bug ... Thanks, Bart.
Created attachment 90259 [details] see comment 4
Bart: thank you for your feedback. On pc Debian x86-64 with master sources updated yesterday, I reproduced this.
Bart: on pc Debian x86-64 with master sources updated today, I noticed that when I opened the file with the color name entry deleted: - first time I go to Color tab : RGB values are not retrieved (0,0,0 => Black) - I go to Area tab and go back to Color tab: RGB values are retrieved Caolán: I noticed that if I added this: *pPageType = PT_COLOR; in cui/source/tabpages/tpcolor.cxx, line 429 so to have this: 427 if( pColorList.is() ) 428 { 429 *pPageType = PT_COLOR; 430 if( *pPageType == PT_COLOR && *pPos != LISTBOX_ENTRY_NOTFOUND ) It worked on master sources (I mean RGB values in Color Tab) Of course, it's just a test and *pPageType == PT_COLOR just below becomes useless with this. With this Opengrok search, http://opengrok.libreoffice.org/search?q=pPageType&project=core&defs=&refs=&path=&hist=, I also noticed a kind of pattern: - tpbitmap.cxx - tpgradnt.cxx - tphatch.cxx and tpcolor.cxx slightly different. But I don't understand how this kind of pattern might work. Any idea?
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7be0997a0235b05fed9d448e642e0575a4e6e017 Related: fdo#54024 decrazy the Dialog Type for a start anyway The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3416803959b2eb472d5946cbeb8048582f83123 Resolves: fdo#54024 color values not showing with custom colors The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
seems to work with that, testing appreciated
With master sources git updated today (b7c7bd3de0fdadaf5e4769e0759d68ad17fb7bd0), I don't reproduce this anymore. Thank you Caolán!