I’ve got a TextButton that sets its background colours using:
setBackgroundColours(Colour(86,122,162),Colours::yellow);Drawing of the background of this button is done in LookAndFeel::drawButtonBackground()
On a MacIntel machine the mouse over color, used to draw a ring around the button comes out white, but on a PPC machine, it comes out black.
The mouse over color is generated using Colour::contrasting(). Has anyone else seen this issue with this call between the two Mac platforms?
Very peculiar - the contrasting() method’s really simple, with no obvious endianness issues that I can see. The correct result would be white, so it’s the ppc version that’s wrong… I’ll see what I can find out…
Mea culpa.
The problem isn’t in the contrasting() code, it’s in my LookAndFeel subclass.
On an Intel based machine, I can call
getLookAndFeel().drawButtonBackground()
and that will lead to my subclass’ drawing method. On PPC, however, the same code fails at runtime.
I thought I had fixed the problem by rewriting the above code as
LookAndFeel theLookAndFeel = getLookAndFeel();
theLookAndFeel.drawButtonBackground();
but then it became clear that instead of calling my subclass, the call ended up going to the default LookAndFeel parent class’ method. The address of the pointer that I use in setLookAndFeel() matches what I see when I go to getLookAndFeel(), but the pointer has lost it’s subclass-ness.
My C++ may be getting hazy. Isn’t that what virtual methods are supposed to allow me to do?
That’s exactly what virtual methods are for. Normally when I’ve had problems like that it’s because bits of the code have got out of step with each other - try doing a full rebuild.
The problem turned out to be a scoping problem.
I had declared a static LookAndFeel object as part of my class, and passed a pointer to that to various setLookAndFeel() calls.
Replacing that with a pointer to a LookAndFeel object, which was allocated in my constructor, and deleted in the destructor worked fine.