Lazarus For Delphi Users/de

From Lazarus wiki
Revision as of 23:45, 4 July 2007 by Mischi (talk | contribs) (typos corrected.)

Deutsch (de) English (en) español (es) français (fr) 日本語 (ja) 한국어 (ko) português (pt) русский (ru) slovenčina (sk)

Diese Beschreibung ist für Leute gedacht, die an Lazarus interessiert sind und Delphi bereits kennen. Sie beschreibt die Unterschiede zwischen den beiden.

Delphi -> Lazarus

Lazarus ist ein Rapid Application Development (RAD) Tool wie Delphi. Das bedeutet, es enthält eine visuelle Komponentenbibliothek 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 die selbe 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 plattformunabhä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 dass Lazarus gegenwärtig unter Linux (i386, x86_64), FreeBSD (i386), MacOSX (powerpc, i386) und Windows (i386, x86_64) läuft.

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

Die erste Aktion bei der Konversion eines Delphi Projekts

Nachdem Lazarus gestartet ist, gehen sie zu Tools und dann zu Convert Delphi Project to Lazarus Project. Das wird nicht alles für sie erledigen, aber ein gutes Stück weiter bringen.

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, die auch die wichtigste Quelldatei ist. Aber alle anderen Informationen werden in der .lpi Datei gespeichert. Daher ist die .lpi Datei die wichtigste 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, dass die aktuellen Editoreinstellungen 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, Cursorpositionen, 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 Quelltexte. Viele von ihnen sehen aus und arbeiten sehr ähnlich wie Delphi. Aber es gibt einen wichtigen Unterschied: Lazarus benutzt nicht den Compiler, um Code-Informationen zu erhalten. Es analysiert die Quelltexte direkt. Dies hat eine Menge von bedeutenden Vorteilen:

Der Quelltext-Editor berücksichtigt Kommentare. Für Delphi sind die Kommentare in den Quellen einfach nur Leerzeichen im Code. Kein Code-Werkzeug funktioniert dort und wenn neuer Code automatisch eingefügt wird, dann wandern ihre Kommentare. Unter Lazarus können sie eine find declaration sogar für Code in den Kommentaren erstellen. Obwohl dies nicht komplett verlässlich ist, funktioniert es oftmals. Und wenn neuer Code eingefügt ist, dann benutzt die IDE einige heuristische Methoden, um Kommentare und Code zusammen zu halten. Zum Beispiel: Es wird die Zeile "c: char; // comment" nicht aufteilen.

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

Beispiel für Local Variable Completion

Gehen sie davon aus, dass 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 und sie 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 nur mit Pascal Bezeichnern, sondern mit allen Wörtern. Es läßt sie alle Wörter in allen geöffneten Dateien wählen, die mit dem 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 unübersichtlich zu machen. Zum Beispiel: Method jumping, Class Completion, find declaration, .. arbeiten alle mit Include Dateien.

Es gibt viele Optionen für die Code Features.

Designer

- Richtlinien

Objektinspektor

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

  1. Nach dem starten von Delphi gibt es ein Objekt-Treeview, welches zum navigieren und auswählen von Objecten unter Darstellung deren Hierarchie genutzt werden kann und so wahlweise die Dropdown-Liste des Objektinspektors ersetzt. In Lazarus ist dieses Treeview fester Bestandteil des Objektinspectors und es ersetzt die Dropdown-Liste völlig. Die Anzeige kann über das Kontextmenü "Komponentenbaum anzeigen" aktiviert bzw. deaktiviert werden.
  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 alternativ eine Schaltfläche auf der rechten Seite der ausgewählten drop-down, welche diese Aktion ebenfalls ausführt.
  3. In Delphi müssen sie den Namen eines Ereignisses in der Editierzeile manuell löschen, um Anhänge zu entfernen. In Lazarus können sie mittels Dropdown "none" auswählen.
  4. Ähnlich wie bei Ereignissen, wird doppeltes Klicken normaler Eigenschaften wie boolean nicht den Wert ändern, sie müssen ihn aus einem drop down wählen. Und um diese zu öffnen mit einem zugeordneten Editorformular, müssen sie auf den '...' Button rechts vom edit/drop-down klicken.

Packages

Kann Lazarus Delphi-Packages installieren und verwenden?

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

Brauchen wir ein speziell für Lazarus erstelltes?

Ja. Erzeugen Sie ein neues Package, speichern sie es im Package Quellen Verzeichnis (normalerweise das selbe Verzeichnis wie das der .dpk Datei), fügen Sie die LCL als benötigtes Paket und schließlich die .pas Dateien selbst 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 beinhaltet, versucht die LCL nur visuelle Komponenten zu liefern, während die meisten nicht-visuellen Komponenten (wie zum Beispiel db access) von der FCL zur Verfügung 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 echten Klone. Änderungen müssen gemacht werden in Anwendungen, Komponenten und Bedienelementen wenn sie portiert werden.

Das Folgende ist unvolständige Beschreibung der wichtigsten Unterschiede oder Inkompatibilitäten zwischen Delphi und Lazarus für Delphi-Benutzer zu liefern. Es behandelt hauptsächlich die Unterschiede der VCL von D4, teilweise aber auch D5, D6, oder D7, mit der gegenwärtigen LCL, wie sie im CVS vorliegt. Insoweit können Unterschiede zu den von ihnen verwendeten Versionen von Delphi und LCL bestehen. Sollten ihnen Unterschiede oder Ungenauigkeiten zwischen dem Folgenden und der aktuellen LCL oder ihrem Delphi auffalen, dann bitten wir sie den vorliegenden Text entsprechend zu modifizieren oder neu Abschnitte anzufügen. Wir möchten diese Beschreibung so umfassend und aktuell wie möglich für alle Lazarus-User zur Verfügung stellen.

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. In aller Regel werden diese Voreinstellungen auch entsprechend verwendet. Im laufenden Programm können sich diese Einstellungen von den Vorgaben von Windows unterscheiden. Ferner wird die TControl.ParentFont Eigenschaft mitgeliefert, welche sicherstellt, daß ein Bedienelement immer seiner parent's Schriftart folgt.

Dies trifft in der LCL nicht immer zu. Die LCL als cross-Plattform/cross-Interface hingegen, benutzt das Widget-Toolset das aktuell auf dem benutztem Betriebssystem verwendet wird. Wenn ihr Desktop also gerade das GTK Interface benutzt, so wird LCL immer die Themes und spezifische Schriftarten für Schaltflächen des GTK Widget-Toolset benutzen.

Das bedeutet, daß die meisten LCL Bedienelemente dem Desktop-Desing des Zielrechners entsprechen werden. Das look and feel ihrer Progammoberfläche kann sich also auf verschiedenen Zielrechnern auch entsprechend der Desktop-Einstellungen ändern.

Bedienelemente ziehen und andocken

In der VCL implementieren die meisten (Win-)Bedienelemente Methoden und Callback-Funktionen für die Handhabung des Ziehens (dragging) und Andockens von Bedienelementen, z.B. Ziehen eines Bedienelements von einem Panel, und Andocken an einem anderen Panel zur Laufzeit.

Diese Funktionalität ist noch nicht implementiert/beendet in der LCL. Sie befindet sich gegenwärtig im Anfangsstadium der Planung und stellt schon einen Teil der Kompatibilität für diesen Verhalten bereit, wenn auch nicht in der exakt selben Art und Weise.

Das bedeutet derzeit, daß kein Bedienelement die folgenden TControl Funktionen, Prozeduren, Eigenschaften oder Ereignisse erben/benutzen wird -

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;

daß die folgenden Klassen nicht existieren/nicht verwendet werden können -

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

und daß die folgenen Funktionen auch nicht benutzbar/inkompatibel sind -

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

TEdit/TCustomEdit

Die Edit-Bedienelemente, welche grundsätzlich gleich in der LCL wie in der VCL funktionieren, besitzen einige Besonderheiten, die bei einer Konvertierung beachtet werden sollten -

  1. Wegen Restriktionen in den Interfaces, arbeitet TEdit.PasswordChar noch nicht mit allen Interfaces (obwohl es mit der Zeit möglich ist), anstelle von TCustomEdit.EchoMode sollte emPassword benutzt werden, falls der Text verborgen werden muß.
  2. On Drag/Dock Ereignisse sind noch nicht implementiert. Für mehr Informationen schauen Sie bitte im vorherigen Abschnitt Bedienelemente ziehen und andocken nach.
  3. Font-Eigenschaften werden üblicherweise ignoriert für die Interface-Konsistenz, für eine detaillierte Beschreibung schauen Sie bitte TControl.Font/TControl.ParentFont an.

(optional) TSplitter -> TPairSplitter

Bitte verbessern sie mich

Es gibt jetzt ein TSplitter Bedienelement in der LCL, so daß kein Bedarf zum konvertieren besteht.

Nichtsdestoweniger, wenn sie es doch wollen, hier ist es beschrieben:

Das folgende basiert lose auf den Fragen von Vincent Snijders in der mailing Liste, und Antworten von Andrew Johnson:

Das in Delphi enthaltene "Splitting"-Control welches zwischen zwei Komponenten platziert werden kann um dem einen oder anderen mehr Platz zu geben wird in der VCL durch einen TSplitter realisiert. Dieses wird oft benutzt, beispielsweise in Delphi zwischen dem angedockten Codeexplorer und dem Quelltextfenster.

In der LCL gibt es dafür allerdings ein eigenes Control, den TPairSplitter, welcher den selben Zweck erfüllt, wie der TSplitter allerdings zu diesem nicht kompatible ist, so sind also, wenn sie ihr Programm von einem TSplitter auf einen TPairsplitter ändern wollen, einige Anpassungen nötig.

Was sind nun genau die Unterschiede?

Der größte Unterschied ist, das ein TSplitter keine "Kinder" besitzt. Stattdessen wird es zwischen zwei Controls positioniert, welche mittels Align ausgerichtet sind. So erlaubt er wärend der Laufzeit die dynamische Größenannpassung dieser Controls. Um dies zu ermöglichen muss links und rechts ein mittels Align ausgerichtetes Control vorhanden sein. (Beispielsweise ein left-aligned Panel + ein left-aligned TSplitter + ein client-aligned Panel).

In der LCL ist der TPairSplitter ein spezielles Control mit zwei Panels. Er kann nur nützlich werden, wenn die zu verändernden Kontrols auf dem beiden Panels liegen. Er vergrößert bzw. verkleinert also die beiden Panel, unabhängig davon, ob sie Komponenten enthalten oder nicht.

Der andere entscheidende Unterschied ist, das der TSplitter der VCL seine Position relativ zu den anderen Komponenten verändert, abhängig von seiner split-Position. In der LCL dagegen besitzt der TPairSplitter durch die Panels eine absolute Position, wie andere Controls auch, welche sich nach den Eigenschaften top und left richtet. So verändert sich die Position nicht automatisch, wenn die Splitt-Position verändert wird. Ist dies erwünscht, ist es nötig, einen entsprechenden Callback zu setzen und die entsprechenden Einstellungen zu setzen. Beispielsweise befindet sich in einem verticalen TPairSplitter eine Komponente mit alClient. Soll diese automatisch bei Größenänderungen des Formulars im Verhältnis angepasst werden, ist es nötig, im OnResize des Formulars die neue Position zu setzen:

 PairSplitter.Position := PairSplitter.Width - PairSplitter.Position; 
Wie kann ich nun existierenden Code, der TSplitter verwendet, zu TPairSplitter konvertieren?

Wenn der Splitter und die Bedienelemente in einer effektiven Funktion (wie form oncreate) erzeugt wurden, sollte die Konvertierung nicht zu schwierig sein, hauptsächlich reorganisieren des Codes, um die Bedienelemente in der Reihenfolge der neuen Hierarchie zu erzeugen und die Vorgänger der Nachfolgerbedienelemente zu setzen, um in die left/top und right/bottom Eigenschaften des PairSplitter aufzuteilen. Ein Beispiel für die Änderungen ist -

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

Beide, VCL und die LCL, bieten eine TCustomTreeView/TTreeView Komponente, die für Baumstrukturen-Listen von Daten mit mehrfachen Knoten und fortgeschrittene Auswahl- und Bilderlisten benutzt wird, und während aktuelle Features vergleichbar sind, sind nicht alle Eigenschaften völlig kompatibel. Hauptsächliche Unterschieder sind wie folgt -

Unvollständige Liste, also update to include TCustomTreeView Mark functions and protected methods

  1. Die LCL bietet TCustomTreeView.Options, eine Reihe von Optionen, welche im Bedienelement eingestellt werden können, um sein Verhalten und Erscheinungbild ändern. Diese Optionen sind :
    • 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 - Passt die Item Höhen automatisch an.
    • tvoHideSelection - Markiert das gewählte Item nicht.
    • 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 - Erlaubt das Auswählen von Zeilen, entsprechend der Ermöglichung von TCustomTreeView.RowSelect
    • tvoShowButtons - Zeigt Schaltflächen, entsprechend der Ermöglichung von TCustomTreeView.ShowButtons
    • tvoShowLines - show node lines, equivalent to enabling TCustomTreeView.ShowLines
    • tvoShowRoot - show root note, equivalent to enabling TCustomTreeView.ShowRoot
    • tvoShowSeparators - zeigt Begrenzungszeichen
    • tvoToolTips - show tooltips for individual nodes
  2. Die LCL bietet zusätzliche Eigenschaften:
    • TCustomTreeView.OnSelectionChange Ereignis
    • TCustomTreeView.DefaultItems, für die Standardanzahl von Items
    • TCustomTreeView.ExpandSignType to determine sign used on expandable/collapsible nodes
  3. Während die meisten On Drag/Dock Ereignisse in der LCL verfügbar sind, sie funktionieren nicht. Für mehr Informationen schauen sie bitte den früheren Abschnitt über Control Dragging/Docking an.

Nachrichten / Ereignisse

The order and frequency of messages and events (OnShow, OnActivate, OnEnter, ...) differ from the VCL and depend on the widgetset. The LCL provides a subset of WinAPI like messages to make porting of Delphi components easier, but almost all LCL messages work a little bit different than the VCL/WinAPI counterpart. The biggest part of Delphi code using WinAPI messages uses them, because the VCL lacks a feature or for speed reasons. Such things will seldom work the same under the LCL, so they must be checked manually. That's why LCL messages are called for example LM_SIZE instead of WM_SIZE (unit lmessages).

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