Highlight & Comment Background Color

I figured out how to change the default inspector-comment background color! :slight_smile:

  1. Change the highlighter color by opening the color palette.
  2. Create an inspector comment.

The background for the comment is the highlighter color.

After you’ve done this, all rainbow chaos breaks loose. Now whenever you create a comment within highlighted text (of any color), the comment background color takes on that highlight color. Generally it seems to stick until you switch it by the steps above, by making a comment on differently-colored highlighted text, or sometimes by selecting “Yellow Marker” from the preset choices, at which point it will then become the yellow marker color until it picks up another color. If you click on any other comments, their background color switches to the current “default” background color. (This last can get very entertaining as the “default” switches while you click, since occasionally it picks up a highlight color. It’s like playing the piano at FAO Schwarz! Only perhaps you’ve never done that, because you live in Cornwall. How sad.)

Doing this in one projects affects all other projects (either opened already or opened after this) until you quit Scrivener–comment background color in the other projects will default to whatever the originally set highlight color was in the first project and is subject to all the other ensuing oddities.

Additionally, once you’ve done this, if you close the project while in revision mode, upon reopening the format bar shows the text as black (though it’s really still the revision color) and the default highlight color has become the revision color (rather than reverting to the yellow marker) and comment background color is now also the revision color (presumably picked up from the highlight).

I feel like I should be able to manipulate this bug for my sinister background-color-changing purposes, but it gets rather crazy rather quickly. At least I’ve finally figured out what it is I’m doing that’s causing this. Even selecting one of the preset marker colors will cause this, if selected via the color palette.

Added to the list for investigation, thanks.

Hmm, I can’t reproduce this at all. Can you provide steps for replication?

Drat, it must be something more I did. I tested on both computers and wiped my preferences and custom colors, but it keeps happening. I’ll test plug-ins (can’t imagine why that would make a difference, but who knows) and whatnot, and piece through the default preferences to see if I can figure out what’s causing this, since otherwise the steps I wrote above make this happen every time I try it. Bah. I’ll get back to you!

Safe mode isn’t doing anything to help either, but I am getting a console message now, although it isn’t really related to this–which is to say, I just got it when starting Scrivener, not when I did the color switch and created new comments with a different default color. But I’m desperate, and perhaps it’s a clue…(doesn’t look too promising to me, but what do I know)

1/11/11 10:25:39 AM Scrivener[127] max y: 464.000000 1/11/11 10:25:39 AM Scrivener[127] max y: 464.000000 1/11/11 10:27:38 AM Scrivener[151] max y: 464.000000 1/11/11 10:27:39 AM Scrivener[151] max y: 464.000000 1/11/11 10:28:40 AM Scrivener[164] max y: 464.000000 1/11/11 10:28:41 AM Scrivener[164] max y: 464.000000

And just to be clear about my directions above, to get this bug you need to choose Format>Highlight>Show Colors or use the Show Colors option from the highlight box on the format bar and then pick a color from the color palette; it doesn’t happen unless you open the color palette.

Oops, that console message is a bit of debugging code I left in there. It can be safely ignored.

I had already tested with the colour palette from “Show Colors”, so still no go I’m afraid…

Argh. I’m running out of ideas. :confused: I activated the guest account and logged in that with safe mode and still the same thing. Trashing the Scrivener preference files and the .clr file didn’t help. My computers are possessed!

Just to be clear, these are the steps I’m taking to try to reproduce this:

  1. Select some text.

  2. Click on the highlighter button in the format bar and hold it down, so that the menu appears, then choose “Show Colors” to open the colour palette.

  3. Choose a colour from the colour wheel in the palette so that the text gets highlighted (although I can’t see it has been highlighted because it is selected at the moment).

  4. Click on the “+” button at the top of the Comments & Footnotes pane to add a comment.

Result: The comment background is yellow, as normal. (The text associated with it still uses the highlight colour, though, because that takes preference of the comment highlight colour because of the Cocoa drawing order.)

All the best,

Ah HA! I’m sorry, I’m just failing at directions. Use the keyboard shortcut to create the comment. I never use the button to add a comment and completely forgot it existed…apparently that is making a difference. So sorry! ::slaps forehead::

Everything else is right, though it shoudln’t make a difference whether the text is selected in the editor or not or whether you’re in text with a highlight.

…So now that I have been reminded of alternative ways to create a comment, it appears that using the toolbar icon or the menu option also get this bug. Only the + button in the inspector is immune.

Ah, okay, I see it now. I’m going to leave it on the ultra-low priority list, though, as I’m not sure if I can do much about it, and if I can it will be very complicated - and it’s quite a minor bug. The trouble is with the way the OS X text system interacts with the colour panel. The text system sends the colour panel more messages than it ever needs to - if the text system has a colour in the text, it talks to the colour panel, and the colour pane in return sends out another “change colour” message. A strange feedback loop goes on, basically. I had to indulge in all sorts of hackery just to get the colour panel to affect the highlight colour (and annotation colour - and you’ve seen how annotation colour can go screwy because of colours in text, for the same reason), because the text system is hard coded so that the colour panel interacts with it in a very particular way.

So, in this instance, it seems that the text system is triggering the colour panel to send out a change colour message when the comment is created. I’ve tested, and the comment is definitely receiving a “change colour” message from the colour panel. There’s no way of suppressing these messages, so the only way is to use torturous logic to try to guess when the messages should be ignored…

So, yeah, this won’t be a high priority, hope you understand. :slight_smile:


Ahh. Yes, certainly. I do remember that insanity of the OS color system. And as I said originally, if I’m careful about it I can manipulate this into changing the default background color for comments, which makes it not a bug but a feature!

Mostly I’m just glad to know it’s not just me and my haunted computers having some kind of psychiatric rainbow experience. :slight_smile:

I would like to see this bug moved up on the priority list after 11 years - I am having the exact same issue as described by the original poster. It’s pretty problematic for me, as I color code my comments and use them a lot in my process. It’s pretty annoying to have to go to each comment one by one to change the color when they’re created with the highlight color, and to have to change them every time you click on them. It does get fixed by quitting the program entirely, but I also use highlighting a lot in my text as part of my process, so to have to completely close the program multiple times when I’m working is also annoying. I know it’s not a big issue, but it has been around a long time it seems.