Lazarus For Delphi Users/ja

From Lazarus wiki
Revision as of 13:43, 2 May 2006 by Saeka-jp (talk | contribs)
Jump to navigationJump to search

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

この記事は、Lazarusに興味があり、すでにDelphiは知っている、という人々向けのものです。 この二つの違いについて記述しています。

DelphiからLazarusへ

Lazarusは Delphiのような、高速なアプリケーション開発ツールです。ビジュアルなコンポーネントライブラリと、IDEがあります。Lazarusのコンポーネントライブラリ(LCL)はDelphiのVCLととても似ています。 ほとんどのユニットと、クラスと、プロパティは、同じ名前と、機能をもっています。これは、移植を簡単にします。しかし、Lazarusは'オープンソースのDelphiクローン'ではありません。ですから、100%の互換性を期待しないでください。

最大の相違点は?

Lazarusは完全にオープンソースで、プラットホームに対し独立しており、強力なFree Pascalコンパイラ(FPC)を使っています。FPCは15以上のプラットホームで動作します。 しかし、すべてのパッケージやライブラリが移植されているわけではありません。ですから、Lazarusは現在のところLinux,FreeBSD,MaxOSX、そしてWin32上で動作します。 (訳注:いくつかのPDAでも暫定的な動作はします。日本語に関する処理の改善に、これから皆さんの力を必要としています。)

Lazarusはこの文章のように終わってはいません。私たちはいつでも、新しい開発者、パッケージ管理者、移植者、ドキュメントの執筆者を募っています。


Delphi IDE から Lazarus IDE へ

プロジェクト

Delphiアプリケーションのメインのファイルは .dprファイルです。Lazarusにおいては、.lpiファイルです。(=Lazarus Project Information) .dprファイルはメインのソースプログラムであり、DelphiのIDEはコンパイラスイッチやユニットなどの情報の一部を入れます。(訳注:すべてではない。オプションファイルなどがある)Lazarusのアプリケーションもメインのソースファイルをlprファイルに入れます。しかし、そのほかのすべての情報をも入れます。ですから、.lpiファイルはとても重要です。

例: Delphiはユニットへのパスを.dprファイルに入れます。たとえば、unit1 in 'path/Unit1.pas'というふうにいれます。このinでパスを指定する方法はDelphi独特であり、(Pascalの文法ではあないので)Lazarus IDEは読むことができないので、こういう方法をつかわないでください。かわりに、コンパイラオプションで、ユニットパスを指定してください。

Delphiはコンパイラオプションを.dprファイルに埋め込みます。たとえば、{$APPTYPE CONSOLE}.というふうにいれます。Lazarus IDEでは、これらは無視されますので、使わないで下さい。かわりに、コンパイラオプションを使ってください。

(訳注:DelphiのdprファイルはPascalの仕様+独自の部分が結構多いですが、Free Pascal Compiler上のLazarusとしては、Free Pascalに特殊な言語拡張をなるべく行わず、純粋にFree Pascal上に実現できるような方法がとられています。Delphiのようにコンパイラオプションを至る所に定義できるのは、便利でもある一方、スキャンしていかないと、有効か無効かが分からず、バグや全体のみとおしが悪くなる両刃の剣といえますので、訳者は良い仕様だと思います。)


ひとつ重要なルールがあります。それは、常にプロジェクトは存在するということです。(訳注:IDEが起動している最中に、ということでしょう) 現在のプロジェクトを"close"する方法は、lazarusを終了するか、他のプロジェクトを開くしかありません。 これは、lazarusのプロジェクトはセッションとしての役割があるからです。これは、現在のエディタの設定が、.lpiファイルに記録され、そのプロジェクトを開いたときに再開できるようになっています。たとえば、あなたがアプリケーションをデバッグしていて、多くのブレークポイントやブックマークを開いていたとしましょう。あなたは、いつでもプロジェクトを保存することができ、lazarusを終了したり、他のプロジェクトを開くことができます。その、デバッグ中に保存したプロジェクトを開くと、(たとえ他のコンピュータで開いたとしても)ブレークポイント、ブックマーク、開いていたファイル、カーソル位置、ジャンプヒストリ、などといったものが、復元できます。

ソースエディタ

ほとんどすべてのキーとショートカットが、enviroment -> editor options->key mappingsで定義可能です。 LazarusのIDEには、ソースのための沢山のツールがあります。それらの多くは、Delphiと見た目も似ており、よくにた働きをします。しかし、一つの重要な相違点があります。すなわち、Lazarusはコード情報を取るために、コンパイラを利用しない、ということです。ソースコードを直接解析します。こうすることで、沢山の重要な利点があります。

ソースエディタは、"comments"と一緒に動作します。Delphiにおいては、ソース中のコメントは、コードの間の場所にあるものにすぎません。自動でコードが挿入されても、特別な働きはしないので、すでに入れたコメントは迷子になってしまうかもしれません。Lazarusでは、コメントの中のコードでさえ、宣言を見つけることができます。 これは、完璧に信頼できるものではないかもしれませんが、よく役に立ってます。新しいコードが挿入されると、IDEは発見的な方法を使ってコメントとコードを結び付けます。たとえば、"c: char; // comment"という行は分割されることはありません。

Delphiの"コード補完"(Ctrl+Space)機能は、Lazarusでは、"Identifier Completion"と呼ばれます。Lazarusにおいて、コード補完は、"自動的なクラス補完"(Delphiとおなじです。)、"ローカル変数補完"、"イベント割り当て補完"のあわせた機能です。これらのすべては、Ctrl+Shift+Cで呼び出され、IDEは、カーソルの位置から、何をなすべきか決定します。

ローカル変数補完の例

ちょうど新しいメソッドを作り、"i:=3;"という命令を書いたとしましょう。

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

識別子"i"の上にカーソルをおいて、Ctrl+Shift+Cを押すと、次のようになります。

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


イベント割当補完の例

オブジェクトインスペクタの良い機能のひとつに、自動的にメソッドを作ること、があります。ソースエディタでやってみてください。

たとえば:

Button1.OnClick:=

代入演算子":="の後で、Ctrl+Shift+Cを押してみてください。


語彙補完 Ctrl+W

識別子補完と似ていますが、パスカルの識別子に対してではなく、すべての語彙に対して補完します。あなたが開いているすべてのファイルの中から、あなたがタイプし始めた文字が同じものの語彙をリストアップし、選択できます。

インクルードファイルのサポート

Delphiではインクルードファイルをサポートしていませんので(訳注:$iがあるので、補完機能が、ということだろう)、多分、みなさんは多くのインクルードファイルを今までに作っていないかもしれません。しかし、インクルードファイルには、大きな利点があります。それは、IFDEFでソースコードを汚さずに、プラットホーム独立なコードを書けるということです。 Lazarusでは、メソッドジャンプ、クラス補完、宣言を見つける、など、すべての機能は、インクルードファイルに対しても働きます。 また、コーディング機能にいろんなオプションがあります。

デザイナ

- ガイドライン

オブジェクト・インスペクタ

DelphiとLazarusのIDEにおいて、オブジェクトインスペクタはコンポーネントプロパティを編集したり、イベントを設定したりするのに使われます。使い方に、いくつかの小さな違いがあります。

  1. Delphi5を起動すると、オブジェクトインスペクタのなかで、階層にしたがって伝統的なドロップダウンリストの中でオブジェクトを選択できるオブジェクトツリービューがあります。Lazarusでは、これは、オブジェクトインスペクタの一部にすぎません。デフォルトのドロップダウンリストのかわりに、右クリックで表示される"Show Component Tree"メニューを使うこともできます。
  2. Delphiでは、空のイベントでダブルクリックすると、自動的にイベントを作成し、ソースエディターがその位置を開きます。Lazarusは右側にボタンがあり、ドロップダウンでこの動作を選択することができます。
  3. Delphiでは、つけられたイベント名は手で消さなくてはなりませんが、Lazarusでは、"(None)"をドロップダウンで選ぶことができます。
  4. Eventと同じように、booleanのような標準的なプロパティをダブルクリックすることで、値は変化しません。ドロップダウンで選択する必要があります。そして、エディターフォームで結び付けられているものを開くには、editやdrop-downの右側にある'...'ボタンをクリックする必要があります。

In the Delphi and Lazarus IDE's the Object Inspector is used to edit component properties and assign events etc. The following are a few minor differences to note in use :

  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 double clicking on a blank event will auto create one and open the Source Editor to that position, in Lazarus there is a button to the right of the selected drop-down which performs this action instead.
  3. In Delphi you must manually delete the name of an event in the edit to remove the attatchement, in Lazarus you can drop down and select "(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

パッケージ

LazarusはDelphiのパッケージをインストールして使うことはできますか?

いいえ、なぜなら、それには、Delphiのコンパイラマジックが必要だからです。

私たちは、Lazarus向けに特別にパッケージを作りたいのですが?

はい。新しくパッケージをつくり、パッケージソースディレクトリに保存してください。 通常は dpkファイルと同じディレクトリです。そして、LCLを必要とするパッケージとして加えて、最後に.pasファイルを加えてください。それを今すぐインストールしたり、プロジェクトで使うことができます。 LazarusとDelphiのパッケージで、いくつかの違いがありますので、lazarusのソース内のdocs/Packages.txtを読んでください。


Can Lazarus install and use Delphi Packages?

No, because they require Delphi compiler magic.

Do we need ones specially made for lazarus?

Yes. Create a new package, save it in the package source directory (normally same directory of the .dpk file), add the LCL as required package and finally add the .pas files. You can install it, or use it in your projects now. There are some differences between Lazarus and Delphi packages, so please read

- see docs/Packages.txt in the lazarus sources.

VCL から LCL へ

VCLとLCLは、ともに、高速なアプリケーション開発向けの、オブジェクト指向の階層的なコンポーネントのライブラリです。しかし、それらは同じではありません。 たとえば、VCLは多くの非ビジュアルなコンポーネントを含みます。一方、LCLは、Free Pascalによって、多くの「ビジュアルでない」コンポーネント(データベースアクセスなど)が提供されていますので、ビジュアルなコンポーネントのみ、を提供しようとしています。 (訳注:データベースの表示については、ビジュアルである。そのなかで使われるデータベースアクセス自体はLCLコンポーネント内に統合される)


While the VCL and the LCL both serve much of the same purpose - of an Object Oriented Component Hierarchy especially geared toward rapid application development, they are not identical. For instance while the VCL provides many non-visual components, the LCL tries to only provide visual, while most non-visual components (such as db access) are provided by the FCL, included with Free Pascal .


加えていうと、多くのコントロールがVCLやその類にあっても、LCLに存在しないかもしれません。同じようなコントロールが両方に存在する場合でも、それらはクローンではありません。 ですから、もし移植をするなら、アプリケーション、コンポーネント、およびコントロールで変更が必要です。

Additionally many controls may not exist in the LCL that are in the VCL, or vica versa, or even when controls do exist in both, they are not clones, and changes must be made in applications, components and controls if porting.

次のことはDelphiユーザのために、DelphiとLazarusの主要な違いや、互換性のない所を、公正に明らかにしようとするものです。これは、主にD4でのVCL(しかし、同時にD5,D6,D7も同様です)と、現在のCVSにあるままの現在のLCLの違いをカバーします。ですから、あなたがいつも使っているDelphiやLCLのバージョンに完全に一致しないかもしれません。もし、これらの記述が正確でないとすれば、他の皆さんの理解のために、ご自由に記述を加えたり、変更してください。

The following is an attempt to provide fairly complete descriptions of major differences or incompatiblities between the two for the Delphi user. It covers differences primarily with the VCL of D4 especially, though at times D5, D6, or D7 as well; and with the current LCL, as is in CVS. As such it may not always be accurate to the version of Delphi you are used to, or completely match the current LCL you have. If you see inacuracies between the following and the LCL as in CVS, or your Delphi feel free to append and modify so as to keep this as comprehensive as possible for all people.

TControl.Font/TControl.ParentFontについて

VCLでは、コントロールにボールドやイタリック、特定のフォント名と字体の特性を使用しますが、通常この値がいつも子へと引き継がれていきます。 さらにいえば、コントロールがいつもParentの字体を確実にする継承するために、TControl.ParentFontプロパティを提供しています。Windows Apearance設定があるにもかかわらず、これが、いつも優先されるということを暗黙に仮定しています。

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.


これはLCLにも、あてはまるわけではありませんし、そうではありません。 現実にクロスプラットフォーム/クロスインタフェースであるLCLは、バランスのとれた手法を好んで採用しようとしています。LCLは、いつでも、どんなウィジェットでのネイティブのDesktop/ツールキットのApearance、Theme設定も使用しようとするでしょう。 例えば、テーマが、ボタンのための特定の字体を供給するGTKインタフェース、およびgtkを使用することがありますが、LCLボタンはいつもこのテーマに沿った字体を使用するわけです。

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.

このことは、ほとんどのLCLコントロールはVCLでしばしば期待されるのと同じレベルの設計上の(フォントなどの)管理機能は持っていない、ということを意味しています。 しかし、使用されるインターフェースにかかわらず、この様に統一的に割り当てられたインタフェースに代わり、Canvasに独自で描画するカスタムコントロールでは、その動作を変更することができます。

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.


例えば太字や、特別な色の字体のLabelが必要な場合、代わりにTStaticTextを使用しなければなりません。 なぜなら、TLabelは特定のコントロールのインタフェースであり、すべてのインタフェースのネイティブなバージョンを供給するのであるならば、その大部分は、不用意なデフォルト設定が利用されるでしょう。


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.

ドラッグとドッキングの制御

VCLでは、実行中に、例えば1個のパネルからコントロールをドラッグして、別のパネルにドッキングできるように、ほとんどのTWinControlからの派生コントロールは、ドラッグ、ドッキングを制御する機能が組み込まれています。

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.

この機能はLCLでは、現在、未完成であり、実装されていません。現在、設計の初期段階です。このタイプのふるまいが、同じような方法で、同等のレベルの互換性を維持するように、最終的には、サポートすべきでしょう。

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.

これは、現在、どんなControlも以下のTControl機能、手順、特性、または出来事を引き継ぐか、または用いないか、を意味します。


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 separate 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 hierarchy 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
(extraneous values removed)
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.

Original Contributors and changes

This page has been converted from the epikwiki version.

  • 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