Start with a new document and type a few words and insert an object like an image or math object. Highlight a word and change the font colour to anything other than the default using the Font color button on the Styles & Formatting toolbar. This causes the colour to change on the button to the last chosen colour, let's say green. Choosing other text at this point and clicking the font color button sets it to this last chosen colour, green. At this point everything is normal. Now select one of the objects and the toolbar changes as appropriate. Click back on any of the text and the Styles & Formatting toolbar returns but with the initial colour, red, on the Font Color button, not the last one you had chosen, green. If you highlight any text and click the Font Color button it is still set to your last choice, green, but doesn't show that colour on the button. Seems like a redraw problem when switching toolbars. I'm using: Version: 4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a on a machine running 64-bit Windows 7 with a Intel i5 processor. This problem also exists in Calc.
A similar problem happens with the highlight button - when the toolbar get redrawn on the screen the button reverts to showing the default colour but it actually remembers the last colour used. The background colour button seems to actually reset to the default colour which is more accurate in some ways because it reverts back to yellow but the button actually shows that it will be yellow. However, like most users I would prefer for it to remember the last colour I was using in the document.
Also, just discovered that once the Font color button and highlight color button have been redrawn with the incorrect colour that if I then start another blank document the Font and Highlight buttons will not take on a different colour on the toolbar and only show the default colour no matter what colour you last used. They do remember your last colour but just don't update/redraw correctly.
I confirm issue about Writer and Calc in 4.1.3.2 under Win7 64bit (I had not time to test Calc behaviour) it's a regression of 3.6.0 release (it works in 3.5.7) and affects any release from then to date including Version: 4.2.0.0.alpha0+ 2013-11-01 build I add GUI expert to CC list. Ivan, is this something you can handle?
Thanks for the report. I have a dirty solution... :)
Tommy, in Calc 3.5.7 what was the color after switching back to the Styles & Formatting toolbar - the last chosen one or the selected cell's font color? (Sorry, can't download 3.5.7 now - my current internet connection is poor.)
Never mind, I've downloaded a 3.5.7.
*** Bug 71955 has been marked as a duplicate of this bug. ***
Bug affects Linux as well as reported in Bug 71955. changed platform to ALL @Ivan(In reply to comment #5) > Tommy, in Calc 3.5.7 what was the color after switching back to the Styles & > Formatting toolbar - the last chosen one or the selected cell's font color? sorry for late reply, Ivan. in Calc 3.5.7 the font color depends on which cell you select... if you select the same cell where you changed the color before, the font color icon reminds that color. if you select another empty cell the font color icon reverts to default color. in Calc 4.1.3 the font color icon always reverts to default color regardless of the cell you choose
Set to NEW, because I don't contribute to LibreOffice anymore. My previous solution didn't work. The problem here is that a color info is lost after destroying and creating a SvxColorExtToolBoxControl on toolbar hide and show, respectively. http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbcontrl.cxx#2429 Adding Winfried, maybe he can help.
(In reply to comment #9) > Set to NEW, because I don't contribute to LibreOffice anymore. > > My previous solution didn't work. > > The problem here is that a color info is lost after destroying and creating > a SvxColorExtToolBoxControl on toolbar hide and show, respectively. > > http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbcontrl. > cxx#2429 > > Adding Winfried, maybe he can help. I will have look at it in due time, am currently busy with calc functions.
A possible solution might be to store the last used colours in the class from which the buttons are created, i.e. ScDLL in the case of Calc. However, this solution does not look right, as ScDLL has nothing to do with data such as last used colours of buttons. It disregards some principles of object oriented programming. Another solution could be to keep the last used colours with the toolbar settings. This way it will even remember the last used colours when starting LibreOffice. But this will be a rather large change and is not familiar terrain for me at all. All in all, I don't think it will be me patching this behaviour.
(In reply to Ivan Timofeev (retired) from comment #9) > The problem here is that a color info is lost after destroying and creating > a SvxColorExtToolBoxControl on toolbar hide and show, respectively. > > http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbcontrl. > cxx#2429 Sounds like we understand this regression pretty well, so Whiteboard -> bibisectNotNeeded
Migrating Whiteboard tags to Keywords: (bibisectNotNeeded)
@Jan: there's a code pointer in comment 9. An easy hack? I can't tell the difficulty...
A polite ping, still working on this bug ?
(In reply to jan iversen from comment #15) > A polite ping, still working on this bug ? I would still like to - at the moment I have been to busy to get to it but I will get to it eventually. For the moment I will release it and when I can actually start working on it I will take it back if it is still free.
A polite ping, still working on this bug
Yes
A polite ping, still working on this bug?
The original problem that the color on the button might not be the same as applied when clicking it, doesn't exist since [1]. The other part that the last applied color should be remembered is also covered by Bug 72991. [1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=584b415924bba22db23a4258062e54973de0ed7c *** This bug has been marked as a duplicate of bug 72991 ***
*** This bug has been marked as a duplicate of bug 113433 ***