LookAndFeel TextEditor::highlightedTextColourId ignored


#1

I have a plugin using a custom LookAndFeel object that calls the following:
setColour(TextEditor::highlightedTextColourId, Colours::white);
My plugin GUI uses Label objects that are editable. In Juce 1.53, this allowed for setting the color of the text while highlighted during edited. However in JUCE 2.0.21, this call has no effect and the highlighted text color is stuck being black. Seems to me like a bug introduced in JUCE 2? And there seems to be no workaround, since there is no Label::colour constant for setting this directly on the Label object (though I wish that were an option), so LookAndFeel seems to be the only way to go.


#2

I just tried this myself and it seems to work perfectly…


#3

Ah I have come to realize that what is happening for me is that my custom LookAndFeel is not being applied at all, and here is what’s happening…

I have a class LookAndFeelChild that inherits from LookAndFeel. I do something like this in my code:

GUIClass::GUIClass::() { LookAndFeelChild look; LookAndFeel::setDefaultLookAndFeel(&look); }
So the LookAndFeelChild instance is allocated on the stack in and then set and forgot, and in JUCE 1.53 this worked because the LookAndFeel class would retain ownership of the object set with setDefaultLookAndFeel() but now with JUCE 2.0 it seems to no longer do this? I can resolve the issue by making LookAndFeelChild look a static variable (or member variable of my GUIClass, or in some way making my reference to it live for the life cycle of my plugin), however the behavior seems to have changed (and I did like the 1.53 behavior of LookAndFeel retaining ownership of a reference to the custom LookAndFeel object). Is this behavior change intentional or a mistake?


#4

No, that could never have worked correctly. It’s impossible for anything to magically keep a stack-based object alive once it has gone out of scope. Perhaps in the old code it just kept a dangling pointer to the deleted object, and you were lucky that the memory didn’t get overwritten.


#5

Sorry, perhaps I am talking about the wrong thing with reference retaining, but the stack-based instance is still valid upon completing the calling to LookAndFeel::setDefaultLookAndFeel and since it worked, I assumed that LookAndFeel stored everything that it needed to store during setDefaultLookAndFeel and then did not need the original object retained externally beyond that point (admittedly I have not looked through the implementation of LookAndFeel::setDefaultLookAndFeel). Perhaps that assumption was wrong and it only happened to work in JUCE 1.53 and now no longer does.


#6

setDefaultLookAndFeel does NOT store a copy of your L&F. So what you’re doing will work… until your function goes out of scope!


#7

Thank you for the clarification. I have updated my code now accordingly. How weird then that it did consistently work for me the previous way in JUCE 1.53…