The Windows graphics interface realizes the roller blind, fades out of fade and pop-up effects, making the interface more attractive. If you want to use these effects in your form, you only need an API function: AnimateWindow!
This API function is simple, you only need to provide your form's handle, the animation of milliseconds, and some specified effects and directions.
Try to add the following code in your form's OnShow event handler:
... AnimateWindow (Self.handle, 250, aw_blend or aw_activate; ...
Execute the project and look at the results. Cool, is it?
This function uses the roller blind effect by default, but you can use AW_SLIDE to get the slide effect, use AW_Center to get collapsed or expanded, with AW_BLEND to get smoothing fade out.
Also, you can add AW_ACTIVATE logo if your form is appearing, or aw_hide if your form will be hidden, this sign reverses the direction of the animation.
When you use roller blinds and fade out, you can specify the effect in the direction of horizontal and vertical axes, add AW_HOR_POSTIVE and AW_HOR_NEGATIVE to set the x-axis, add W_VER_POSTIVE, or AW_VER_NEGATIVE to set the Y axis.
When you use the AW_Center flag, all of these flags can be omitted.
Test different logo combination and look at the results!
-------------------------------------------------- ------------------------------
When you have played a while, you will find a strange place: some controls are normal, other control drawings have an error, and some are not in painting! !
The reason is very simple, but the solution is very troublesome.
The MSDN document says the Windows program of the control in the form must handle WM_PRINT or WM_PRINTCLIENT messages so that they are used with the AnimateWindow API function. These messages are used when Windows requires a display environment other than the screen (such as a printer, where the screen outfit is mapped). This document says that the window programs for normal controls and dialogs have processed these messages.
This explains some control drawing normal: TButton, Tcheckbox, and Tradiobutton they have and manage the button controls underground so they can process the message correctly.
Drawing an error control is an intermediate type that has a button control but some parts make the application DEPHI Tcanvas instead of Windows GDI, such as TEDIT, TRICHEDIT, and other such controls.
The invisible controls are those who do not have ordinary controls, they are the descendants of Tgraphic, such as Tshape and TBevel. These controls will never draw because they do not receive the required messages.
However, for the Delphi object derived from TwinControl, you can take and process the WM_PrintClient message like this:
UNIT TestGroupbox;
Interface
Uses Windows, Messages, Sysutils, Classes, Graphics, Controls, Forms, Dialogs, Stdctrls;
type TTestGroupBox = class (TGroupBox) private {Private declarations} protected {Protected declarations} procedure WMPrintClient (var Msg: TMessage); message WM_PRINTCLIENT; public {Public declarations} published {Published declarations} end;
PROCEDURE register;
IMPLEMentation
Procedure register; begin registercomponents ('' Test '', [TTestGroupBox]); END;
{TTestGroupBox}
Procedure TTestGroupBox.WMPrintClient (VAR Msg: TMESSAGE); Begin Paintto (HDC (Msg.wParam), 0, 0); END;
End.
This is an example component that is derived from TGROUPBOX. Since TGROUPBOX is not a normal window control, WM_PRINTCLIENT is not processed. The program adds a message processing function and uses a PaintTo method in a different display environment, which is directly when it is.
It's a trouble now: Every control of your form must be modified, and you must modify all your objects to safely use the AnimateWindow API function.
