I have a drawablebutton created: "DrawableButton* UserSelect = new DrawableButton ("User", DrawableButton::ImageAboveTextLabel);", that at a certain situation i need to put the button text, not when painting.
The situation is that i use the function "UserSelect->setButtonText("Text to put");" and the application crashes giving access violation and opens the header "juce_CharPointer_UTF8.h";
What am i'm doing wrong ?
On normal button i can setButtonText anytime without any problem.
It will make it easier for people to read your post.
Also you are posting code fragments--these don't mean much without context. If you want anyone to be able to help you, you'll have to give them context by letting them know what function, class, thread, etc you are executing the function from.
Try removing all of the other button images except the normalImage. Remove any other unnecessary code, too. Try to create the smallest program possible that both (1) compiles and (2) replicates your issue.
On a different note, how are you managing the lifetime of this object?
DrawableButton* UserSelect = new DrawableButton ("UserButton", DrawableButton::ImageAboveTextLabel);
Your question about lifetime of this object i cannot understand, sorry, but i explain what i have done.
This DrawableButton makes part of a component that is used for login on my application, and when i destroy the component, i have it declared as a "ScopedPointer<DrawableButton> UserSelect" and i do UserSelect = nullptr when "destroying" the component.
DrawableButton* UserSelect = new DrawableButton ("UserButton", DrawableButton::ImageAboveTextLabel);
If you declare a local variable with the same name as a member variable it will take precedence over it. What you're actually doing is creating a new pointer, assigning it your newly created object and never acually touching your member variable. So when try to use your UserSelect member later on it doesn't actually contain a valid object.
To fix it, don't re-declare the UserSelect identifier, just assign it. E.g. the line above becomes:
UserSelect = new DrawableButton ("UserButton", DrawableButton::ImageAboveTextLabel);
Better still, unless this object needs to be created and deleted dynamically make it a member object, not a pointer. That way you know it will always be vailid and you won't have to assign it an object or de-reference the pointer each time you use it.
Try turning up your warning levels, there should be one to highlight this issue.
Also it's a good style idea to not start your variable names with a capital letter, it makes it hard to distinguish what is a variable and what is a class name, especially on forums where there is no syntax highlighting.
What you have done is redefine a local variable with the type DrawableButton* in your constructor. This is a local override, meaning, it is a different variable than the variable with the same name that has the type ScopedPointer<DrawableButton>. As you have it, you aren't changing the variable ScopedPointer<DrawableButton> UserSelect, which by default contains a null pointer to a DrawableButton. So when you go to use it, the operator->() will return a null pointer. It's important to distinguish that UserSelect itself won't actually be null if you've declared it to be a ScopedPointer in your class declaration. Note, however, that the operator==() and operator!=() have been overloaded so that you can check to see if the pointer managed by ScopedPointer is nullptr.
ScopedPointer<> helps you manage the "birth" and "death" or lifetime of the object in a safe way.
I'm no expert, I'm just trying to help a fellow JUCE fan along ;)
the lifetime of the component was short
Exactly the opposite! What happened was that you created a new object on the heap in your constructor. Then once the constructor exited, that object still existed on the heap, but the pointer to that object on the heap fell out of scope, so you no longer had access to the object it pointed to. So the object stayed on the heap until your program exited or was terminated by the OS. This is called a "dangling pointer" and it resulted in a memory leak. This is not what caused your crash, though!