19th Chapter-delphi Custom Parts Development (II.) (3)

These three expressions use Registerpropertyeditor three different uses:

The first of the most typical

It registers the property editor Tcomponentproperty for all tcomponent type properties. Typically, when you register a property editor for a type attribute, it can apply to all of these types of properties, so the second and third arguments are nil.

The second expression registers a specific type of property editor

It registers the property editor for specific properties of a particular part, in which case the editor is used for the Name property of all parts.

The third expression is between the first and the second expression

It registers the property editor for all properties of the Tmenuitem type of the part Tmenu.

19.2.2.2 Create Event

Events are a very important part of a part. An event is a join of a system event that the part must respond to and a piece of code that responds to the event. The response code is called the event-handling process, and it is always written by the part user. By using events, the application developer does not need to change the part itself to customize the behavior of the part. As part writer, using events enables the application creator to customize all the standard Delphi components. To create an event, you should understand that:

What is an event

How to implement standard events

How to define your own events

1. What is an event

An event is a mechanism, or a method pointer, to a particular method of a particular object instance, which is what happens to a join and some code. From the perspective of a part user, an event is a name related to a system event, such as OnClick, that a user can assign a specific method to call. For example, the button buttonl has the OnClick method, by default Delphi produces a Buttonlclick method in the form containing the button, and assigns it to the onclick. When a Click event occurs on a button, the button invokes the method assigned to the onclick Buttonlclick:

A part user sees an event as code written by the user, and a system-invoked approach when an event occurs.

Events from the part writer's perspective have more meaning. The most important thing is to provide a place where users write code to respond to specific things.

To write an event, you should understand that:

Event and Method pointers

Event is a property

Event-handling procedure type

Event-handling procedures are optional

⑴ event is a method pointer

Delphi uses method pointers to implement events. A method pointer is a specific pointer to a specific method of a particular object instance. As a part writer, you can use the method pointer as a container. Your code calls a user-defined method as soon as it finds something happening.

Method pointers work like other procedure types, but they keep an implied pointer to an object instance. All controls inherit a method named Click to handle the Click event. The click Method invokes the user's Click event handling process.

Procedure Tcontrol.click;

Begin

If assigned (onclick) then OnClick (Self);

End

If the user assigns the control's OnClick event a process (Handle), the mouse-click control will cause the method to be invoked.

⑵ Event is a property

The part implements the event in the form of a property. Unlike most other attributes, events do not use methods to implement the read and write sections. The event property uses the same type of private Object field as the property. By convention domain name in front of the property name plus "F". For example, a pointer to the OnClick method exists in the Tnotifyevent type Fonclick domain. The OnClick event property is declared as follows:

Type

Tcontrol=class (tcomponent)

Private

Fonclick:tnofifyevent; {Declare the domain that holds the method pointer}

Protected

Property Onclick:tnotifyevent read Fonclick write Fonclick;

End

Like other types of properties, you can set and change the value of an event at run time. The primary benefit of making an event a property is that the part user can use Object Inspector to set the event handling process at design time.

⑶ Event-handling process type

Because an event is a pointer to an event-handling procedure, the event property must be a method pointer type, and the code used as the event-handling procedure must be the corresponding object's method.

All event methods are procedures. In order to be compatible with an event of the given type, an event-handling procedure must have the same number of parameters as the same order as the same type. Delphi defines the method types for all standard event-handling processes, and when you create your own events, you can use an existing event type, or create a new one. Although it is not possible to do event processing with functions, the return information can be obtained with the Var parameter.

A typical example of passing the Var parameter during event handling is the Tkeypressevent type keypressed event. The tkeypressevent definition contains two parameters. A indicates which object produces the event. Another indicates that the key is pressed:

Type

Tkeypressevent=procedure (sender:tobject var key:char) of Object;

The key parameter usually contains the characters that the user presses the key. In some cases, the user of the part may want to change the character value. For example, in the editor, force all characters to uppercase, in which case the user can define the following event handling procedures:

Procedure tforml.editlkeypressed (Sender:tobject; var key:char);

Begin

Key: = Upcase (key);

End

You can also use the var parameter to allow the user to override the default processing.

The ⑷ event handling process is optional

When you create an event for a part, remember that the part user may not be writing the process of the event. This means that your part cannot be faulted because the part user did not write the processing code. The optional nature of this event-handling process is two:

① part users do not have to deal with events

Events are always occurring in Windows applications. For example, moving the mouse over a part causes Windows to send a large number of mouse-move messages to the part, which passes the mouse message to the OnMouseMove event. In most cases, a part user does not need to care about the MouseMove event, which does not cause problems because the part does not depend on the process of mouse events. Similarly, custom parts cannot rely on the user's event-handling process.

② Parts Users can write arbitrary code during event handling

In general, there is no restriction on the user's code in the event-handling process. Parts of the Delphi Part Gallery are supported in this way to minimize the likelihood that the written code will produce errors. Obviously, the user code cannot be prevented from having logical errors.

2. How to achieve standard events

All control of the Delphi belt inherits most of the Windows events, which are standard events. Although all of these events are embedded in standard control, they are protected by default, which means that users cannot access them, and when you create controls, you can select these events to make them available to users. Embedding these standard events into your custom control needs to be considered as follows:

What is a standard event

How to make an event visible

How to modify the standard event handling process

⑴ what is a standard event

There are two standard events: for all control and for standard Windows control only.

The most basic events are defined in the object Tcontrol. window controls, graphical controls, and custom controls all inherit these events, and the following lists the events for all controls:

OnClick Ondragdrop Onenddrag OnMouseMove

OnDblClick OnDragOver OnMouseDown OnMouseUp

All standard events define the corresponding protected dynamic method in Tcontrol, except that no "on" such as the OnClick event calls a method named Click.

Standard control (inherited from Twincontrol) has the following events:

OnEnter OnKeyDown OnkeyPress OnKeyUp OnExit

As with standard events in Tcontrol, window controls also have corresponding protected dynamic methods.

⑵ How to make an event visible

The declaration of standard events is protected, and you need to declare them public and published if you want them to be accessible at runtime or at design time. Re-declaring an attribute without describing its implementation inherits the same implementation method, but only changes the access level. For example, to create a part and make its OnClick event appear at run time, you can add the following part declaration:

Type

Tmycontrol=class (Tcustomcontrol)

Published

Property OnClick; {make onclick visible in Objectinspector}

End

⑶ How to modify the standard event handling process

If you want to modify the way a custom part responds to an event, you can rewrite the code and assign it to the event. The protected that will join the method declaration for each standard event is a deliberate consideration. Through, the coverage implementation method, can modify the internal event processing process, by invoking the inheritance method, can maintain the standard event processing process.

It is important to call the order of inherited methods. Typically, the inherited method is invoked first, allowing the user's event-handling process code to be executed before your custom code. There are, however, also instances of executing your own code before invoking the inherited method.

Here is an example that overrides the Click event:

Procedure Tmycontrol.click;

Begin

Inherited Click; {Perform standard processing, including invoking event-handling procedures for your own custom code}

End

3. Define your own events

It is rare to define a new event. A new event needs to be defined only if the part behaves completely differently from any other event. Defining a new event typically consists of three steps:

Triggering events

Defining the type of processing process

declaring events

Invoke Event

⑴ Trigger Event

The first key to defining your own events is that you don't have to consider what triggers the event when using standard events. For certain events, the problem is obvious. For example, a MouseDown event occurs when a user presses the left mouse button, and Windows sends a WM_LBUTTONDOWN message to the application. When a message is received, a part calls its MouseDown method, which in turn invokes the user's OnMouseDown event-handling procedure code. But there are some events that are not so well described. For example: A roller bar has a onchange event that can be triggered by various circumstances, including keystrokes, mouse clicks, or other changes in the system. When defining an event, you must invoke the correct event for all occurrences.

Here's how Tcontrol handles WM_LBUTTONDOWN messages, Domousedown is a private implementation that provides a general way to handle left, right, and middle buttons, and converts the parameters of Windows messages to the values of MouseDown methods.

Type

Tcontrol = Class (Tcomponent)

Private

Fonmousedown:tmouseevent;

Procedure Domousedown (Var message:twmmouse; Button:tmousebutton;

Shift:tshiftstate);

Procedure Wmlbuttondown (var message:twmlbuttondown);

Message M_lbuttondown;

Protected

Procedure MouseDown (Button:tmousebutton; Shift:tshiftstate;

X, Y:integer); Dynamic

End

Procedure Tcontrol.mousedown (Button:tmousebutton; Shift:tshiftstate; X, Y:integer);

Begin

If assigned (Fonmousedown) then

Fonmousedown (Self, Button, Shift, X, Y); {Calling event handling}

End

Procedure Tcontrol.domousedown (Var message:twmmouse; Button:tmousebutton;

Shift:shiftstate);

Begin

With the message do

MouseDown (Button, Keystoshiftstate (Keys) + Shift, xpos, YPos); {Calling dynamic Method}

End

Procedure Tcontrol.wmlbuttondown (var message:twmlbuttondown);

Begin

inherited; {Perform default handling}

If cscapturemouse in ControlStyle then

MouseCapture: = True;

If csclickevents in ControlStyle then

Include (Fcontrolstate, csclicked);

Domousedown (Message, Mbleft, []); {Calling the regular Mouse-down method}

End

When two things-state change and user interaction-occur, the processing mechanism is the same, but the process is slightly different. User interaction events will always be triggered by Windows messages. State change events are also related to Windows messages, but they can also be generated by attribute changes or other code. You have full control over the triggering of custom events.