I did manage to change the AnimationDelay-type static field in the xpTaskBarBox class... and it worked. But, as I was doing this, it occured to me that you might want to rethink your approach to animation slighty:
Correct me if I'm wrong, but it seems delay is a limit to how fast you move each frame of the animation. The top speed of the animation is probably related to a timer of some sort. So if delay is 0, it is at maximum animation speed.
The way I would do this is to specify in milliseconds how long the animation should last. In the case of task boxes... if I put 1000 then it should take 1 second to fully collapse/expand. But if I put 0, it should just collapse/expand instantly with no animation.
I don't think you can achieve this with the delay field as it is coded.
You might find a smoother animation in situations where the CPU is overburdened. In 'real world' applications, the expand/collapse animation may trigger a lot of code as child controls start repainting themselves. But with the animation specified this way, it would at least be consistent even if the timer misses a tick.
ADAdministrator Syncfusion Team November 11, 2002 07:24 AM
The problem with the approach you suggest is that in slower painting scenarios, the resultant animation might get "jumpy".
The reason is that the no. of animation positions is set (10 in this case) and say after drawing the 1st position, the logic will determine that it's now time for drawing the 9th position and draw it, skipping the intermediate steps. That will result in unseemly animation.
What would be ideal is to be able to automatically adjust the no. of positions based on time taken to paint. But the time taken to paint is not deterministic.
So, I think the best way to handle this is for the programmer to determine the preferred AnimationDelay and the no. of AnimationPositions(we will make this configurable) based on a case by case basis.