Bug 54024

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!