Renaming them textOffColourId and textOnColourId would make it clear and “break” the code where it needs to be changed.
Yes, I suppose so…
Can we set the size for the component without calling its resized() method. Like When i create a button with a particular image I know the width and Height of the Image and i know what values ( width and Height ) to set to the button.
If i say setSize() in constructor of the class it will call resized() of the Button.
One way is to store the values in the member variable. ( not a good option )
Other way is setComponentProperty( T(“Width”) , pImage->getWidth() ). ( I dint like ).
Is there any other way to set the Size in constructor.
[quote=“Godwin”]Can we set the size for the component without calling its resized() method. Like When i create a button with a particular image I know the width and Height of the Image and i know what values ( width and Height ) to set to the button.
If i say setSize() in constructor of the class it will call resized() of the Button.
One way is to store the values in the member variable. ( not a good option )
Other way is setComponentProperty( T(“Width”) , pImage->getWidth() ). ( I dint like ).
Is there any other way to set the Size in constructor.[/quote]
Not sure I understand… What’s wrong with it calling resized()? I often setSize() in a constuctor with no problems.
ok… So there is no probelm in setting the size in the Constructor using setsize()???
But we cant use SetBounds in constructor for any reason…
No, it’s generally ok to change the size in the constructor… Obviously you have to bear in mind all the many nasty c++ pitfalls that you can hit whenever you do anything complex in a constructor, but there’s no fundamental reason why you shouldn’t do it.
wat about the getWidth() and getHeight() methods… It wont return the proper value. We not set the bounds for the component yet…??
pChild->setBounds( 0, 0 , getWidth() , getHeight() ); Will cause crash in constructor right…
Eh?? You seem a bit confused. getWidth will return whatever the component’s width is. Initially it’s zero.
MyCompConstructor()
{
addAndMakeVisible (child = new ChildComp());
child->setSize (getWidth(), getHeight()); // child is set to (0, 0)
setSize (100, 100);
child->setSize (getWidth(), getHeight()); // child is set to (100, 100)
}
Could you make the DrawableButton label colour customizable?
BTW that would be neat if we could give our own Drawable button when creating preferences pages.
I’m amazed that it’s not already customisable! I’ll sort that out…
The addition of DrawableButton::textColourId is cool but it look only on the lookandfeel not on the component itself before as other component do usually.
instead of
Is this normal ?
Thanks,
Drat, sorry - that’s what I meant to write.
I would like to get your suggestion on managing Colour Id’s for my Custom controls, most of them uses gradient background. Right now, I am not sure what is the Id value I should start with( in order to avoid clash with existing Id’s).
Thanks,
Sabu
Well, I’ve used maybe 100 values, so if you pick a random 32-bit number, the chances are about about 40000000:1 that it’ll be free!
Well here we use something like 0x20000000 as base offset for all our colours id to avoid that problem. However I wish there were a colourId registry instead that would be more elegant.
Even better having unique named symbols like symbol(“Label::textColourId”) would both avoid colourId conflicts and allow reflexion for automated skin support.
I recently added the Identifier class, which would be ideal for this kind of thing, but it’d be a bit of a pain to retro-fit it. Revamping the way the look-and-feels work will be part of all my new jucer work though, so I’ll come up with a better solution.
glad to hear that. The backward compatibility is definitely the painful task.
I am trying to deal with the colours for my components via the look and feel as opposed to explicitly set the colours per component. Does it make sense to make the following method take an optional argument of the colour to be returned?
const Colour LookAndFeel::findColour (const int colourId)to become something like:
const Colour LookAndFeel::findColour (const int colourId, const Colour defaultColour = Colours::black)The look and feel is the thing that’s supposed to supply the default colours, so that doesn’t really feel right… You can just use LookAndFeel::setColour to make sure the default is there when the l+f is created.
I have added some custom colour ids to a custom l+f. So when my custom components paint, they get the colour based on the id. I didn’t want to do the painting in my custom l+f because this wouldn’t work with other non-custom l+f. Perhaps I am missing the obvious here?