LnF changes

Hi Jules,

Could you please notify us in the forum or make changes break build when changing LnF function definition ?

Looks like drawTreeviewPlusMinusBox broke silently very recently

moving from 

virtual void drawTreeviewPlusMinusBox (Graphics&, int x, int y, int w, int h, bool isPlus, bool isMouseOver)


 virtual void drawTreeviewPlusMinusBox(Graphics&, const Rectangle<float>& area,
                                               Colour backgroundColour, bool isItemOpen, bool isMouseOver)


Maybe there are other stuff that I don't know of.

I really don't mind changing my code for the better but just want to know that I should change it.


Wonderful thing about is git, is that you can trace every change, before doing mindless updates.

This one changed recently also:

void TreeViewItem::paintOpenCloseButton(Graphics &g, const Rectangle< float > &area, Colour backgroundColour, bool isMouseOver)

Check out SourceTree:


It makes tracing changes easier, and combined with Araxis Merge, you can put all code under the microscope.

Also, why you aren't using continuos integration and build testing?

That way you can easily trace when something breaks.

This can be avoided with best practices, it's not a particular Juce issue, you have to adapt to it being a moving framework, and sometimes you may have to freeze your code and do updates as necessary, or keep up with the changes.

Whenever I change that virtual methods like that, I always add a private virtual override that will break any existing code, and avoid those nasty silent bugs. If you search for the JUCE_CATCH_DEPRECATED_CODE_MISUSE you'll see these all over the codebase.

It seems unlikely that I'd have forgetten to do it for that method, but in refactoring the L+F classes I did change a huge amount of code, and perhaps one got overlooked.. Or perhaps you don't have the JUCE_CATCH_DEPRECATED_CODE_MISUSE flag enabled. Either way, sorry!

I don't mind having the build break.

Here it doesn't, THIS is the issue., especially with virtual function.

With C+11 I could use the override keyword but we are not there yet.


Thank you for the best practice lecture but I'm sure having to check every commit looking for changes that may break your code is not one of those.


Looks like our posting overlapped - hopefully you'll see my reply above.

Thanks Jules.


indeed those have missed the deprecated flagging when doing the LnF refactoring.

I used to see those for other modifications you have done in the past.

How can I set the TreeViewItem text colour? I could not find a colourId for it or a lookandfeel routine.

Never mind I found it.