No, they’re not too slow…they’re too fast
Here’s the problem:
I’ve got two buttons, and one shows the down state when clicked quickly, and the other doesn’t. If I press and hold on the one that doesn’t, then I see the down state, so the graphics are all there. If I break on my lookAndFeel style, I see that after a click, there are two separate paint() calls that come with two separate states.
The problem is that the down state seems to get blown away by the On state so fast that I never have the chance to see the down state. If I change setTriggeredOnMouseDown() to false, then I see the down state, but the button seems sluggish compared to the other.
Has anyone else experienced this? Is there a good way to set how long the down state will be shown before it switches to On?
Well if it’s being triggered by the mouse, it’ll be down to how fast you click and whether it has time to actually do a paint in between the down and up events. Can’t think of any neat ways of making it delay repainting without doing a lot of hackery…
it turns out that the problem has to do with our app doing a lot of work that ties up the main thread as a user pushes a button. This, in turn slows down redraws to the screen, and the end result is that the down button state isn’t seen.
Setting setTriggeredOnMouseDown() to true allows the down state to be
got similar problem here too. we have a heavy duty initialisation (on it’s own thread) which the GUI is supposed to convey IE “initialising” plus a flashing light. I had to put the thread priority to 3 before anything would happen! does not seem to slow it down though. strangely, the also intense “reset” process does not freeze the GUI?
It’s mostly up to Windows when it send the repaint message - it sometimes seems to avoid repainting windows that aren’t in the foreground if the cpu use is high…