Difference between revisions of "Lazarus For Delphi Users/de"

From Lazarus wiki
((optional) TSplitter -> TPairSplitter)
(TControl.Font/TControl.ParentFont)
Line 89: Line 89:
  
 
====TControl.Font/TControl.ParentFont====
 
====TControl.Font/TControl.ParentFont====
In the VCL it is quite common and normal to use a specific font name and font properties such as bold and italics for controls, and expect this value to always be followed. Further is provided the TControl.ParentFont property which ensures that a control will always follow its parent's font. Again the implicit assumption being that these values will always be followed, even regardless of Windows Apearance Settings.  
+
In der VCL ist es ziemlich einfach und normal, einen spezifischen Schriftart-Namen und Schriftart-Eigenschaften wie 'fett' und 'kursiv' für die Bedienelemente zu benutzen, und zu erwarten, daß diesem Wert immer gefolgt wird. Ferner wird die TControl.ParentFont Eigenschaft mitgeliefert, welche sicherstellt, daß ein Bedienelement immer seiner parent's Schriftart folgt. Außerdem bewirkt die eingeschlossene Voraussetzung, daß diesen Werten immer gefolgt wird, sogar ungeachtet der Windows Erscheinungs Einstellungen.  
  
This is not always true in the LCL, nor can it be. The LCL being cross-platform/cross-interface in nature prefers to take a balanced aproach, and instead will always try to use native Desktop/Toolkit Apearance or Theme settings on any widgets. For example if using a GTK interface, and the gtk theme supplies a specific font for buttons, then LCL buttons will always try to use this font.  
+
Dies trifft nicht immer in der LCL zu. Die LCL als cross-Plattform/cross-Interface in ihrer Natur bevorzugt eine ausgeglichene Vorgehensweise zu ergreifen, und stattdessen versucht sie immer natürliche Desktop/Toolkit Design oder Themeneinstellungen für jedes Widget zu benutzen. Zum Beispiel wenn sie ein GTK Interface benutzen, und das gtk Thema unterstützt spezifische Schriftarten für Schaltflächen, dann werden die LCL Schaltflächen immer versuchen, diese Schriftart zu benutzen.  
  
This means that most LCL controls do not have the same level of design control that is often expected in the VCL, rather only those custom controls which are Canvas drawn instead of interface allocated can consistantly be modified in this manner regardless of the Interface used.
+
Das bedeutet, daß die meisten LCL Bedienelemente nicht die selbe Ebene (level) der Designsteuerung haben, die oft in der VCL erwartet wird, eher können die kundenspezifischen Bedienelemente, welche Canvas gezeichnet sind, durchweg modifiziert werden in dieser Art und Weise ungeachtet des benutzten Interfaces, anstelle eines zugewiesenen Interfaces.
  
If for instance a Label with a bold/special color font is required, a TStaticText must be used instead, as TLabel is an interface specific control and all interfaces will supply a native version, and most will have default settings which will be used regardless.
+
Wenn beispielsweise ein Label mit einer fetten/spezialfarbigen Schriftart benötigt wird, muß stattdessen ein TStaticText benutzt werden, da TLabel ein Interface spezifisches Bedienelement ist und alle Interfaces eine native Version bereitstellen werden, und die meisten werden Voreinstellungen haben, welche trotzdem benutzt werden.
  
 
====Control Dragging/Docking====
 
====Control Dragging/Docking====

Revision as of 16:31, 4 September 2005

Delphi -> Lazarus

Lazarus ist ein Rapid Application Development (RAD) Tool wie Delphi. Das bedeutet, es enthält eine visuelle Komponenten Bibliothek und eine IDE. Die Lazarus component library (LCL) ist sehr ähnlich zu Delphi's VCL. Die meisten Units, Klassen und Eigenschaften haben den selben Namen und Funktionalität. Dies macht eine Portierung (von Delphi zu Lazarus) einfach. Aber Lazarus ist kein 'Open Source Delphi Klon'. Erwarten sie daher keine 100%ige Kompatibilität.

Die größten Unterschiede

Lazarus ist komplett Open Source, ist Plattform unabhängig geschrieben und benutzt den mächtigen Free Pascal Compiler (FPC). FPC läuft auf mehr als 15 Plattformen. Aber nicht alle Packages und Bibliotheken sind portiert, so daß Lazarus gegenwärtig unter Linux, Free/Open/NetBSD, MacOSX und Win32 läuft.

Lazarus ist nicht komplett, wie es dieser Text ist. Wir suchen ständig neue Entwickler, Package-Entwickler, Portierer, Dokumentations-Schreiber, ... .

Delphi IDE -> Lazarus IDE

Projekte

Die Hauptdatei einer Delphi Anwendung ist die .dpr Datei. Die Hauptdatei eines Lazarus Projekts ist die .lpi Datei (Lazarus Project Information). Eine .dpr Datei ist die Hauptquelle eines Programms und die Delphi IDE speichert hier einige Informationen über die Compiler Schalter und Units. Eine Lazarus Anwendung hat auch eine .lpr Datei, welche auch die wichtigste Quelldatei ist. Aber alle anderen Informationen werden in der .lpi Datei gespeichert. Daher, die wichtige datei ist die .lpi Datei.

Eine wichtige Regel: Es gibt immer ein Projekt. Der einzige Weg um ein Projekt "zu beenden" ist, Lazarus zu beenden oder ein anderes Projekt zu öffnen. Das ist so, weil ein Lazarus Projekt auch eine "Sitzung" ist. Das bedeutet, daß die aktuellen Editor Einstellungen auch in der .lpi Datei gespeichert sind und wiederhergestellt werden, wenn sie das Projekt wieder öffnen. Zum Beispiel: Sie debuggen eine Anwendung, setzen eine Menge Haltepunkte (Breakpoints) und Lesezeichen (Bookmarks). Sie können das Projekt jederzeit speichern, Lazarus schließen oder ein anderes Projekt öffnen. Wenn sie das Projekt wieder öffnen, sogar auf einem anderen Computer, werden alle ihre Haltepunkte, Lesezeichen, geöffneten Dateien, Cursor Positionen, Sprunghistorie, ... wieder hergestellt.

Quelltext Editor

Beinahe alle Tasten und Abkürzungen (short cuts) können definiert werden unter Einstellungen->Editoreinstellungen->Tastaturbelegung.

Die Lazarus IDE besitzt eine Menge von Werkzeugen für Quellen. Viele von ihnen sehen aus und arbeiten sehr ähnlich zu Delphi. Aber es gibt einen wichtigen Unterschied: Lazarus benutzt nicht den Compiler um Code Informationen zu erhalten. Es analysiert die Quellen direkt. Dies hat eine Menge von bedeutenden Vorteilen:

Der Quelltext Editor arbeitet mit "Ausführungen" (comments). Für Delphi sind die Ausführungen in den Quellen einfach nur Leerzeichen im Code. Keine Code Eigenschaft funktioniert dort und wenn neuer Code automatisch eingefügt wird, dann reisen ihre Ausführungen. Unter Lazarus können sie eine find declaration sogar für Code in den Ausführungen erstellen. Obwohl dies nicht komplett verläßlich ist, funktioniert es oftmals. Und wenn neuer Code eingefügt ist, dann benutzt die IDE einige heuristische Methoden, um Ausführungen und Code zusammen zu halten. Zum Beispiel: Es wird nicht die Zeile "c: char; // comment" aufteilen.

Delphi's "Code Completion" (Ctrl+Space) wird "Identifier Completion" genannt unter Lazarus. Der Lazarus Begriff "Code Completion" ist ein Feature, welches "Automatic Class Completion" (das gleiche wie unter Delphi), "Local Variable Completion" und "Event Assignment Completion" kombiniert. Alle von ihnen werden augerufen mit Ctrl+Shift+C und die IDE ermittelt über die Cursor Position, was gemeint ist.

Beispiel für Local Variable Completion

Gehen sie davon aus, daß sie gerade eine neue Methode erzeugt haben und die Anweisung schreiben "i:=3;"

procedure
TForm1.DoSomething;
begin
i:=
3
;
end
;

Positionieren sie den Cursor über den Bezeichner "i" und drücken sie Ctrl+Shift+C um zu erhalten:

procedure
TForm1.DoSomething;
var
i: Integer;
begin
i:=
3
;
end
;

Beispiel für Event Assignment Completion

Ein nettes Feature des Objektinspektors ist die automatische Erzeugung von Methoden. Das selbe können sie im Quelltext Editor erhalten.
Zum Beispiel:

Button1.OnClick:=

Positionieren sie den Cursor hinter den assign operator ":=" und drücken sie Ctrl+Shift+C.

"Word Completion" Ctrl+W

Es arbeitet ähnlich wie die "Identifier Completion", aber es funktioniert nicht mit Pascal Bezeichnern, aber mit allen Wörtern. Es läßt sie alle Wörter in allen geöffneten Dateien wählen, die mit den selben Buchstaben beginnen.

Unterstützt Include Dateien

Delphi unterstützt es nicht, und daher haben sie wahrscheinlich noch nicht viele Include Dateien erstellt. Aber Include Dateien haben einen großen Vorteil: Sie machen es möglich, Plattform unabhängigen Code zu schreiben ohne ihren Code durch IFDEFs zu verwirren. Zum Beispiel: Method jumping, Class Completion, find declaration, .. arbeiten alle mit Include Dateien.

Es gibt viele Optionen für die Code Features.

Designer

- Richtlinien

Objekt Inspektor

In den Delphi und Lazarus IDE's wird der Object Inspector benutzt, um Komponenteneigenschaften zu editieren und Ereignisse zuzuweisen etc. Die folgenden Zeilen zeigen einige kleinere Unterschiede zur Beachtung für den Gebrauch  :

  1. Starting in Delphi 5 there is an Object Treeview which can be used to navigate and select objects according to hierarchy in addition to the traditional drop down list in the Object Inspector. In Lazarus this is part of the Object Inspector and is used in place of the default drop-down, you can select to use/not use it from the right click menu with "Show Component Tree"
  2. In Delphi wird ein Doppelklick auf ein leeres Ereignis automatisch eines erzeugen und den Quelltext Editor an dieser Position öffnen, in Lazarus gibt es eine Schaltfläche auf der rechten Seite der ausgewählten drop-down, welche stattdessen diese Aktion ausführt.
  3. In Delphi müssen sie den Namen eines Ereignisses manuell löschen in der Editierzeile, um Anhänge zu entfernen, in Lazarus können sie drop down und auswählen "(None)".
  4. Similarly to Events, double clicking regular properties such as boolean will not change the value, you must select it from a drop down. And to open those with an assigned editor form, you must click the '...' button to the right of the edit/drop-down

Packages

Kann Lazarus Delphi Packages installieren und verwenden?

Nein, wiel sie die Delphi Compiler Magie benötigen.

Brauchen wir eines speziell für Lazarus gemacht?

Ja. Erzeugen Sie ein neues Package, speichern sie es im Package Quellen Verzeichnis (normalerweise das selbe Verzeichnis der .dpk Datei), fügen sie die LCL als benötigtes Package hinzu und schließlich füegen siw die .pas Dateien hinzu. Sie können es installieren, oder es jetzt in ihren Projekten verwenden. Es gibt einige Unterschiede zwischen Lazarus und Delphi Packages, daher lesen sie bitte

- die docs/Packages.txt in den Lazarus Quellen.

VCL -> LCL

Während die VCL und die LCL beide meist den selben Zwecken dienen - zu einer Objekt orientierten Komponenten Hierarchie besonders verzahnt in Richtung Rapid Application Development, sind sie nicht identisch. Zum Beispiel während die VCL viele nicht-visuelle Komponenten mitliefert, versucht die LCL nur visuelle Komponenten zu liefern, während die meisten nicht-visuellen Komponenten (wie zum Beispiel db access) von der FCL geliefert werden, welche in Free Pascal enthalten ist.

Zusätzlich mögen viele Bedienelemente, die in der VCL enthalten sind, nicht in der LCL existieren, oder umgekehrt, oder sogar wenn Bedienelemente in beiden existieren, sind sie keine Klone, und Änderungen müssen gemacht werden in Anwendungen, Komponenten und Bedienelementen wenn sie portiert werden.

Das Folgende ist ein Versuch, ziemlich komplette Beschreibungen , der wichtigsten Unterschiede oder Inkompatibilitäten zwischen den beiden für die Delphi Benutzer zu liefern. Es behandelt die Unterschiede hauptsächlich mit der VCL von D4 im Speziellen, aber hin und wieder auch D5, D6, oder D7; und mit der gegenwärtigen LCL, wie sie in CVS ist. Als solche mag es nicht immer akkurat sein zu der Version von Delphi, welche sie benutzen, oder komplett übereinstimmen mit der gegenwärtigen LCL, die sie haben. Wenn sie Ungenauigkeiten erblicken zwischen dem Folgenden und der LCL wie in CVS, oder ihrem Delphi, dann fühlen sie sich frei, es zu modifizieren und neues anzuhängen, um es so umfassend wie möglich zu bewahren für alle Leute.

TControl.Font/TControl.ParentFont

In der VCL ist es ziemlich einfach und normal, einen spezifischen Schriftart-Namen und Schriftart-Eigenschaften wie 'fett' und 'kursiv' für die Bedienelemente zu benutzen, und zu erwarten, daß diesem Wert immer gefolgt wird. Ferner wird die TControl.ParentFont Eigenschaft mitgeliefert, welche sicherstellt, daß ein Bedienelement immer seiner parent's Schriftart folgt. Außerdem bewirkt die eingeschlossene Voraussetzung, daß diesen Werten immer gefolgt wird, sogar ungeachtet der Windows Erscheinungs Einstellungen.

Dies trifft nicht immer in der LCL zu. Die LCL als cross-Plattform/cross-Interface in ihrer Natur bevorzugt eine ausgeglichene Vorgehensweise zu ergreifen, und stattdessen versucht sie immer natürliche Desktop/Toolkit Design oder Themeneinstellungen für jedes Widget zu benutzen. Zum Beispiel wenn sie ein GTK Interface benutzen, und das gtk Thema unterstützt spezifische Schriftarten für Schaltflächen, dann werden die LCL Schaltflächen immer versuchen, diese Schriftart zu benutzen.

Das bedeutet, daß die meisten LCL Bedienelemente nicht die selbe Ebene (level) der Designsteuerung haben, die oft in der VCL erwartet wird, eher können die kundenspezifischen Bedienelemente, welche Canvas gezeichnet sind, durchweg modifiziert werden in dieser Art und Weise ungeachtet des benutzten Interfaces, anstelle eines zugewiesenen Interfaces.

Wenn beispielsweise ein Label mit einer fetten/spezialfarbigen Schriftart benötigt wird, muß stattdessen ein TStaticText benutzt werden, da TLabel ein Interface spezifisches Bedienelement ist und alle Interfaces eine native Version bereitstellen werden, und die meisten werden Voreinstellungen haben, welche trotzdem benutzt werden.

Control Dragging/Docking

In the VCL most (Win)Controls implement methods and callback functions for handling dragging and docking of controls, eg. dragging a control from one panel, and docking it onto another panel at run time.

This functionality is currently unimplimented/unfinished in the LCL, though it is currently in the initial stages of planning, and should eventually support some level of compatibility for this type of behaviour, if not in the exact same manner.

This currently means that no Control will inherit/use the following TControl functions, procedures, properties, or events -

Protected
function
GetDockEdge(MousePos: TPoint): TAlign;
function
GetDragImages: TDragImageList;
function
GetFloating: Boolean;
function
GetFloatingDockSiteClass: TWinControlClass;
procedure
DoEndDrag(Target:TObject); X, Y: Integer);
procedure
DockTrackNoTarget(Source: TDragDockObject; X, Y: Integer);
procedure
DoEndDock(Target: TObject; X, Y: Integer);
procedure
DoDock(NewDockSite: TWinControl;
var
ARect: TRect);
procedure
DoStartDock(
var
DragObject: TDragObject);
procedure
DragCanceled;
procedure
DragOver(Source: TObject; X, Y: Integer; State: TDragState;
var
Accept: Boolean);
procedure
DoEndDrag(Target: TObject; X, Y: Integer);
procedure
DoStartDrag(
var
DragObject: TDragObject);
procedure
DrawDragDockImage(DragDockObject: TDragDockObject);
procedure
EraseDragDockImage(DragDockObject: TDragDockObject);
procedure
PositionDockRect(DragDockObject: TDragDockObject);
procedure
SetDragMode(Value: TDragMode);
property
DragKind: TDragKind;
property
DragCursor: TCursor;
property
DragMode: TDragMode;
property
OnDragDrop: TDragDropEvent;
property
OnDragOver: TDragOverEvent;
property
OnEndDock: TEndDragEvent;
property
OnEndDrag: TEndDragEvent;
property
OnStartDock: TStartDockEvent;
property
OnStartDrag: TStartDragEvent;
public
function
Dragging: Boolean;
function
ManualDock(NewDockSite: TWinControl; DropControl: TControl;
ControlSide: TAlign): Boolean;
function
ManualFloat(ScreenPos: TRect): Boolean;
function
ReplaceDockedControl(Control: TControl; NewDockSite: TWinControl;
DropControl: TControl; ControlSide: TAlign): Boolean;
procedure
BeginDrag(Immediate: Boolean; Threshold: Integer);
procedure
Dock(NewDockSite: TWinControl; ARect: TRect);
procedure
DragDrop(Source: TObject; X, Y: Integer);
procedure
EndDrag(Drop: Boolean);
property
DockOrientation: TDockOrientation;
property
Floating: Boolean;
property
FloatingDockSiteClass: TWinControlClass;
property
HostDockSite: TWinControl;
property
LRDockWidth: Integer;
property
TBDockHeight: Integer;
property
UndockHeight: Integer;
property
UndockWidth: Integer;

that the following classes do not exist/are unuseable -

TDragImageList =
class
(TCustomImageList) TDockZone =
class
TDockTree =
class
(TInterfacedObject, IDockManager) TDragObject =
class
(TObject) TBaseDragControlObject =
class
(TDragObject) TDragControlObject =
class
(TBaseDragControlObject) TDragDockObject =
class
(TBaseDragControlObject)

and that the following functions are also unuseable/incompatible -

function
FindDragTarget(
const
Pos: TPoint;
AllowDisabled: Boolean) : TControl;
procedure
CancelDrag;
function
IsDragObject(sender: TObject): Boolean;

TEdit/TCustomEdit

The Edit controls, while functioning essentialy the same in the LCL as the VCL, do have some issues to be aware of in converting -

  1. Due to restrictions in the Interfaces, TEdit.PasswordChar does not work in all interfaces yet(though in time it may), instead TCustomEdit.EchoMode emPassword should be used in the event text needs to be hidden.
  2. On Drag/Dock Events are not yet implemented. For more information please see earlier section on [LazarusForDelphiUsers#Control Dragging/Docking|Control Dragging/Docking].
  3. Font Properties are usually ignored for interface consistancy, for detailed explanation as too why please see TControl.Font/TControl.ParentFont

(optional) TSplitter -> TPairSplitter

Please Improve Me

There is now a TSplitter control in the LCL, so no need to convert it.

Nevertheless, if you want, here it is explained:

The following is loosely based on questions by Vincent Snijders on the mailing list, and responses by Andrew Johnson:

In the VCL, "Splitting" controls, that is a handle which can be dragged between two components to give one more or less space then the other, is accomplished by a TSplitter. This is often seen, for instance in the Delphi IDE between the docked Code Explorer and Source Viewer.

The LCL provides its own Control called a TPairSplitter, which serves the same type of purpose, however it is not compatible, so "repairing" broken VCL code or Delphi DFM's will be necesary in the event of porting code, even though much is shared in common between the two.

So what exactly are the differences?

Well the biggest differences are a VCL TSplitter has no children, instead it is placed between two controls aligned properly, and allows resizing between them at runtime, regardless its own size. It must have two controls aligned on each size to do anything. A simple example would be form with a Left Aligned Panel, a left aligned Splitter, and a second client aligned panel. On run time you could then realign the size given each panel by dragging on the handle provided by this Splitter control.

On the LCL hand however, a TPairSplitter is a special kind of control, with two panels, and it can only be usefull if the controls to split are on these panels, but it will still perform a split between those panel whether or not anything is on them. So following the prior example, you would have a form with a TPairSplitter aligned client, and a panel aligned client on its left side, and a panel aligned client on its right side.

The other important difference is that in the VCl, since the TSplitter is its own TControl, then the position is kept relative to the other controls on resize, so for instance a client panel will grow while the other panels will not, thus the split position is relative to the alignment of the split controls,

In the LCL since the side panels are seperate then the TPairSplitter has a Position property which is absolute relative to top or left. so on resize the actual position does not change according to contents, so a callback must be set to ensure the ratio is kept on resize if this is important.

For example if the Right side of a vertical split needs to have alClient like behaviour, you need to add a form resize callback which does something like :

PairSplitter.Position := PairSplitter.Width - PairSplitter.Position; 
So how can I convert existing code using TSplitter to the TPairSplitter?

If the splitter and controls are created within an actual function(like form oncreate), conversion shouldn't be too difficult, primarily reorganize the code to create the controls in order of new heirarchy and set the parents of the child controls to split to the left/top and right/bottom portions of the PairSplitter. An example of the changes being -

VCL LCL
var
BottomPanel: TPanel
;
VerticalSplitter: TSplitter
;
LeftPanel: TPanel
;
HorizontalSplitter: TSplitter
;
MainPanel: TPanel
;
begin
BottomPanel:= TPanel.Create(Self)
;
with
(BottomPanel)
do
begin
Parent:= Self
;
Height:=
75
;
Align:= alBottom
;
end
;
VerticalSplitter:= TSplitter.Create(Self)
;
with
(VerticalSplitter)
do
begin
Parent:= Self
;
Align:= alBottom
;
end
;
HorizontalSplitter:= TSplitter.Create(Self)
;
with
(HorizontalSplitter)
do
begin
Parent:= Self
;
align:= alLeft
;
end
;
LeftPanel:= TPanel.Create(Self)
;
with
(LeftPanel)
do
begin
Parent:= Self
;
Width:=
125
;
Align:= alLeft
;
end
;
MainPanel:= TPanel.Create(Self)
;
with
(MainPanel)
do
begin
Parent:= Self
;
Align:= alClient
;
Caption:=
'Hello'
;
end
;
end
;
var
BottomPanel: TPanel
;
VerticalSplitter: TPairSplitter
;
LeftPanel: TPanel
;
HorizontalSplitter: TPairSplitter
;
MainPanel: TPanel
;
begin
VerticalSplitter:= TPairSplitter.Create(Self)
;
with
(VerticalSplitter)
do
begin
Parent:= Self
;
Align:= alClient
;
Width:= Self.Width
;
Height:= Self.Height
;
SplitterType:= pstVertical
;
Position:= Height -
75
;
Sides[
0
].Width:= Width
;
Sides[
0
].Height:= Position
;
end
;
HorizontalSplitter:= TPairSplitter.Create(Self)
;
with
(HorizontalSplitter)
do
begin
Parent:= VerticalSplitter.Sides[
0
]
;
Width:= Self.Width
;
Height:= VerticalSplitter.Position
;
align:= alClient
;
SplitterType:= pstHorizontal
;
Position:=
125
;
end
;
LeftPanel:= TPanel.Create(Self)
;
with
(LeftPanel)
do
begin
Parent:= HorizontalSplitter.Sides[
0
]
;
Align:= alClient
;
end
;
MainPanel:= TPanel.Create(Self)
;
with
(MainPanel)
do
begin
Parent:= HorizontalSplitter.Sides[
1
]
;
Align:= alClient
;
Caption:=
'Hello'
;
end
;
BottomPanel:= TPanel.Create(Self)
;
with
(BottomPanel)
do
begin
Parent:= VerticalSplitter.Sides[
1
]
;
Align:= alClient
;
end
;
end
;

So as you can see, farely consistant with most control hierarchy. And if you are familiar with DFM's, the changes needed for DFM->LFM conversion should be farely obvious from the above, as they are the same sort of changes in Parent/Owner etc.

So the above example would be something like -

Delphi DFM
(exteranous Werte wurden entfernt)
Lazarus LFM
(most width, height etc removed)
object
VerticalSplitter: TSplitter Height
=
3
Cursor
=
crVSplit Align
=
alBottom
end
object
HorizontalSplitter: TSplitter Width
=
3
Align
=
alLeft
end
object
BottomPanel: TPanel Height
=
75
Align
=
alBottom
end
object
LeftPanel: TPanel Width
=
125
Align
=
alLeft
end
object
MainPanel: TPanel Align
=
alClient
end
object
VerticalSplitter: TPairSplitter Align
=
alClient SplitterType
=
pstVertical Position
=
225
Height
=
300
Width
=
400
object
Pairsplitterside1: TPairSplitterIde
object
HorizontalSplitter: TPairSplitter Align
=
alClient Position
=
125
object
Pairsplitterside3: TPairSplitterIde Width
=
125
object
LeftPanel: TPanel Align
=
alClient Width
=
125
end
end
object
Pairsplitterside4: TPairSplitterIde
object
MainPanel: TPanel Align
=
alClient
end
end
end
end
object
Pairsplitterside2: TPairSplitterIde
object
BottomPanel: TPanel Align
=
alClient Height
=
75
end
end
end

TCustomTreeView/TTreeView

Both VCL and the LCL provide a TCustomTreeView/TTreeView component, used for tree structured lists of data with multiple nodes and advanced selection and Image lists, and while actual features are comparable, not all properties are entirely compatible. Primary differences are as follows -

Incomplete list, also update to include TCustomTreeView Mark functions and protected methods

  1. The LCL provides a TCustomTreeView.Options, a set of options which can be set on the control to change its behaviour and apearance. These options are :
    • tvoAllowMultiselect - enables multi node select mode, equivalent to enabling TCustomTreeView.MultiSelect in the D6 VCL
    • tvoAutoExpand - Auto Expand nodes, equivalent to enabling TCustomTreeView.AutoExpand
    • tvoAutoInsertMark - Update the Drag preview on mouse move.
    • tvoAutoItemHeight - Adjust the item heights automatically.
    • tvoHideSelection - Do not mark the selected item.
    • tvoHotTrack - use Hot Tracking, equivalent to enabling TCustomTreeview.HotTrack
    • tvoKeepCollapsedNodes - When shrinking/folding nodes, keep the child nodes
    • tvoReadOnly - make Treeview read only, equivalent to enabling TCustomTreeview.ReadOnly
    • tvoRightClickSelect - allow using Mouse Right Clicks to select nodes, equivalent to enabling TCustomTreeView.RightClickSelect
    • tvoRowSelect - allow selecting rows, equivalent to enabling TCustomTreeView.RowSelect
    • tvoShowButtons - show buttons, equivalent to enabling TCustomTreeView.ShowButtons
    • tvoShowLines - show node lines, equivalent to enabling TCustomTreeView.ShowLines
    • tvoShowRoot - show root note, equivalent to enabling TCustomTreeView.ShowRoot
    • tvoShowSeparators - show seperators
    • tvoToolTips - show tooltips for individual nodes
  2. The LCL provides additional properties:
    • TCustomTreeView.OnSelectionChange event
    • TCustomTreeView.DefaultItems, for the default number of Items
    • TCustomTreeView.ExpandSignType to determine sign used on expandable/collapsible nodes
  3. While most On Drag/Dock Events are available in the LCL they do not work. For more information please see earlier section on Control Dragging/Docking.

Mitwirkende und Änderungen

Diese Seite wurde von der epikwiki Version konvertiert.

  • Initial import and formatting - VlxAdmin 9/26/2003
  • Begin VCL -> LCL with a section on TSplitter -> TPairSplitter - Andrew Johnson 9/30/2003
  • Add TControl.Font/TControl.ParentFont to VCL -> LCL - Andrew Johnson 9/30/2003
  • Update TEdit/TCustomEdit section in VCL -> LCL - Andrew Johnson 10/1/2003
  • Add Control Dragging/Docking to VCL -> LCL - Andrew Johnson 10/1/2003
  • Added "Object Inspector" to Delphi IDE -> Lazarus IDE - Andrew Johnson 10/1/2003
  • Added initial "TCustomTreeView/TTreeView" to VCL -> LCL - Andrew Johnson 10/1/2003
  • Added introduction to VCL -> LCL - Andrew Johnson 10/1/2003
  • Fixed some typos - Vincent 10/2/2003
  • Fixed Typo User:Kirkpatc 20 May 2004