XControl
class (in XForms.pas unit)
XControl class is declared in XForms.pas
unit to be closer to XForm declaration and to have access to its private fields. XControl
is a descender of XVisual class and it is intended to be
base class for visual controls, placing on form. This is similar TControl in Delphi VCL,
but remember, that in contrast to VCL, where base class for all objects is TPersistent,
XCL objects do not provide capability of reading its original state from form definition.
This allow not to link stream support modules, input/output routines needed to read data
from executable and recognize it and do not create form definition blocks in executable.
As a result, application made with XCL (called as APPLET)
has dramatically small size.
Disadvantages of this are evident: inconvenience for programmers
because it is necessary to place controls on forms only at run time. Programming in XCL,
at design time developer can work only with pascal code. No ObjectInspector, no double
click on event to create event handler, no components palette and so on. But all this is
generously repaid by extremely small size of the applet, and You do not ever need to
distribute bpl- or dpl-files to do it!
XControl <= XVisual <= XClass <= TObject
XControl properties:
- returns parent form (i.e. Parent if it is a type of XForm, or ParentForm of parent control). I.e., parent form is defined as top level parent XClass object and to provide parent form for control, it must be created with parameter, which is not nil, but is XForm or XControl having ParentForm. Otherwise (when in call of constructor parent is nil) control is created with no parent and can not receive mouse or keyboard events. |
- returns True if Visible and all parents are visible (including parent form). |
- returns True if the control is current in form. Set it to True to focuse it. Focused controls receive keyboard input and can change its appearance. Remember, that in XCL (vs VCL) self-painting non-windowed controls also can be focused (focusing is only emulating by redirecting keyboard input from parent form, which is actually focused in that case). |
- aligning factor. Takes no desired effect if add-on XAligns.pas is not used in applet (by call UseAligner). |
- creation order of control and it is used also to define tabulating order, in which controls are enumerated when user tabulate between its using keyboard (if XKeyboardEvens.pas unit is attached). Take in attention, that in XCL there is no possible to change TabOrder after creating controls. |
- this special property is intended to work with add-on ResizeAntiFlicker to exclude control from autoscrolling during form resizing. It is usually set to True for controls, which content is always centered. This allows to avoid some kinds of flicks. |
Properties, inherited from XVisual:
Properties inherited from XClass:
XControl methods:
- similar the same function of XForm, it returns children control, located at the given position (only Visible controls are taking into consideration, and if IgnoreDisabled is True, only Enabled ones). If two children controls are overlapped, last created is returned. |
- transforms point coordinates from bounding area of control to screen, taking into consideration bounds from parent control (so, if Parent is nil, or ParentForm is nil, this function has no sense). |
- similar function above, converts screen coordinates of given point to bounding coordinates of control. These both converting functions are usually not used by controls and if not called in your code, are not inserted into builded applet. |
- similar the same function of XForm object, it is intended to return the rest of client area after applying all left-right and top-bottom alignments if any - to get know bounds rectangle for control aligning with alClient attribute. In real, this function just call evnt On_GetAvailableClientRect of global object GlobalFormsManager if it is assigned. And this event is assigned only if add-on unit XAligns.pas is used in applet (by callign UseAligner). |
- this abstract function must return True or False constantly for given class,
derived from XControl (i.e., if it was already returned True, it is advisable to return
True forever. |
- Following three procedures are intended to provide controls even non-windowed with ability to respond on mouse events. Therefore, mouse events are ignoring for XForm if add-on unit XMouseEvents.pas is not used in your applet (by calling UseStdMouse). If this last is not used, applet is smaller a little, but self-painting controls can not respond to mouse events, because three methods below never called. |
|
- Like mouse processing procedures above, next three procedures are called in respond to keyboard events (for currently focused control, if any). But this is occuring only in case if add-on unit XKeyboardEvents is used in applet (by calling UseKeyboard). |
- this procedure can be called in your applet to simplify allocation of visual
space of form between controls. As it was said earlier, XForm can not read its initial
state from executable. So, it is necessary to create controls manually and set its initial
state, including size and position. This procedure can help to do it, allowing place
controls in desirable visual order instead of changing its BoundsRect property. Parameter Align if it is True is used to align left or top side of placing control with correspondent side of base Control, (which side is aligning, depends on NewPos: for ppRight and ppLeft, top side is aligned, and for ppTop and ppBottom, left side coordinately). If You are using add-on XControlAutoPlace, You may call this method only to start allocating of newly created control from new vertical column (because the add-on provides placing of new control below of bottom control). |
- this function returns size, which could be sufficient to fit all the content of the control and can be used in autoresizing of controls, containing given control as a member (in combined controls). In partial, this function is overriden in XLabel, XButton and some others. |
Methods, inherited from XVisual:
Remember, that not all controls are windowed. Self-painted controls (XCustomControl and its descendents) are using its parent window to show and paint itself, so You do not need to override this method for those controls. |
Methods inherited from XClass:
Tasks.
Usually You have not to descend controls directly from XControl. To
create new self-painted non-windowed control., use XCustomControl,
and to create mfc-based windowed control, use XMfcControl as
a base class. Controls in XCL are placed onto parent form at run time
Any XVisual descender can have any XClass descendent as a child. But only descenders of XVisual
are taking in consideration when children are enumerated (e.g. to find control at the
given position or to decide which object has to be responsible for mouse events and so
on). But those children which are not XVisual-based but are
XClass-based, therefore are deleted automatically when its
parent is destroying. This is similar to relationship between TForm and TComponent in
Delphi VCL (excluding that XClass objects can not be visual
at design time).