looks like there is no way to display a Mouse-over image when the ImageButton is “Down”. Is that correct, or am I missing something?
(Thats probably Button related:) When switching “DOWN” the button seems to switch the Image immediately, while when switching “UP” it toggles after void clicked() - or probably only because the ToggleState is set during clicked().
I am asking since in my Application the buttons switch hardware states which takes some milliseconds. So its noticeable different timing between DOWN and UP. I would like my inherited button to be responsible to set the ToggleState (not any magic), so my button can change its state only after the hardware has reacted. This gives a feedback in both ways to the user.
I am not sure why there is no public copy constructor (and no public = operator as well). My application would hold its dynamically created buttons in a std::deque or similar; currently it only can do so by using a dynamically allocated button.
If you don’t give it a “down” image, then it’ll use the over image for it.
If your code is blocking the message thread for long enough that you’re seeing a noticeable glitch in the button repaints, then you should probably be using a background thread, shouldn’t you?
Components are designed to be used as virtual classes. Although you can obviously write a component class with a copy constructor, you really should never try to use them as if they have value semantics, because of the danger of slicing.
Yeah, but then I don’t have a “DOWN” image for the button anymore… Thats no progress…
Thats correct. But since the only task of my application is to switch a very few hardware features that would be a bit over-engeneered, also the hardware response is some milliseconds, just long enough to notice a difference. I just wondered why the button-down action changes the Image, while Button-up relies on some handling.
No, I can’t since the assignment operator is also private. So I would have no chance to initialize the inherited component. Its not a big deal though, but would make my use-case cleaner. (I don’t want to copy live-buttons; I want to put them into a container. I am doing this because the amount of buttons and the buttons itself are generated on run-time depending on some run-time states.)
BTW, the ScopedPointer<> also has a private assignment operator, which makes it unusable in std::deque or similar.
Sorry, I guess I just don’t understand your question about the button states.
You certainly can write your own component class with copy/assignment operators, but you can’t expect the base class to copy itself, because copying a Component makes no sense (think about it: would it copy all its child components? What about all the listeners that are registered? Would the new copy be added to the same parent as the original? Etc etc… there are many reasons why it wouldn’t work)
It’s not possible to write a scoped pointer class that works in std containers using c++98. That’s why c++11 introduced the std::unique_ptr class, which you should use if you need to do that.
Thanks, again,
If you set a BP in clicked() the BP will be triggered after changing the image when going from UP to DOWN, but it will be triggered before there is any chance to change the image when going from DOWN to UP. Its not a big deal, but I thought you might be interested as its not consistent. The consequence is that the image changes before my derived button can handle it in one case and after my derived button handles it in the other case.
I don’t want to copy components I want to put them in a std::queue container. But its not important as I can do so by creating them dynamically (with new()).
