TAdvSmoothExpanderPanel 1.0.4.0
We have a scenario where a TAdvSmoothExpanderPanel is trying to expand to a height greater than the allowed height. The allowed height of the panel is restricted based on the form layout, such as control align, anchors, and such. Our form layout will be corrected. But I think TAdvSmoothExpanderPanel should detect this as well.
In TAdvSmoothExpanderPanel.AnimateExpand, when AnimateDouble returns True, the code attempts to change the height:
if a then
begin
FEnableResize := false;
Height := Round(hto);
Changed;
FExpHeight := Height;
FEnableResize := true;
end
If Height is not set to the expected value (Round(hto)), the animation should stop. Or if the height doesn't change at all, it should stop. In our scenario, the height reached 121 and would not go any 'taller'. But FExpHeightTo was 144. The result was a constant flicker that consumed about 80% of a single CPU.
I'm also disappointed that FExpTimer is always Enabled. It has an Interval of 10 (1/100th of a second) and is always enabled, even if FDoAnimate = False. Yet the OnTimer event does absolutely nothing if FDoAnimate = False. It seems that the timer could easily be enabled and disabled when FDoAnimate changes.
Is this usage of TTimer typical of the smooth components or is this a bug/oversight? I'd hate to think now have dozens of timers enabled and firing for no reason on forms where we're using a lot of smooth controls.
Jon
This will be improved in v1.0.4.1.
It will take in account scenarios where Height can't be set and although impact of the running timer is neglectable (just one boolean check) it will be disabled by default as well.
Thanks Bruno.
On the timer, it isn't the impact of the code that executes when the timer fires. It is the impact of the timer itself. Timers are a limited resource (http://blogs.msdn.com/b/oldnewthing/archive/2009/08/27/9886147.aspx). Ok, perhaps not as limited as they once were. But we often have to increase the desktop heap for our Windows XP customers because with everything running on their workstation, resource allocations start to fail.
I'm sure you know that Windows generates a WM_TIMER message that is sent to WndProc and that message has to be dispatched. So it is a little more than "just one boolean check" occurring 100 times a second. If I have 40 components on a form and each has an enabled timer that isn't currently needed for anything, that's wasteful. And it does contribute to an application's performance.
So again, thanks for making the improvements. They are appreciated.