Lazarus For Delphi Users/ja

│ 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と同じく、RAD（Rapid Application Development、手早くアプリケーションを開発できる）ツールの一つです。ビジュアルなコンポーネントライブラリと、IDEがあります。Lazarusのコンポーネントライブラリ(LCL)はDelphiのVCLととても似ています。ほとんどのユニットと、クラスと、プロパティは、同じ名前と機能をもっています。これは、移植を簡単にします。しかし、Lazarusは'オープンソースのDelphiクローン'ではありません。ですから、100%の互換性を期待しないでください。

最大の相違点は？

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

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

Delphi のプロジェクトを Lazarus 用に変換するためにまず必要なこと

Lazarus を起動し、 Tools メニューから Convert Delphi Project to Lazarus Project を選んで下さい。これで全てが解決する訳ではありませんが、大変役立つはずです。Lazarus IDE の変換ツールは一般に一方通行であり、逆の変換はできないことに注意して下さい。プロジェクトを Delphi でも Lazarus でもコンパイルできるように Delphi との互換性を維持する必要がある場合は、Lazarus IDEではなく XDev Toolkit の利用を考えて下さい。

ユニコードのサポート

2007バージョンまでの Delphi はユニコードをサポートせず、Windows が利用していた ANSI エンコーディングを採用していました。2008バージョン以降の Delphi はユニコードをサポートするようになり、UTF-16 を用いて文字列をエンコードしています。

一方、Lazarus は UTF-8 を用いたユニコードサポートを始めました。詳しくは LCL Unicode Support を御読みください。.

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を押してみてください。

手続呼出補完の例

今 "DoSomething(Width);" という文を書き終えた所だとします:

procedure SomeProcedure;
var
  Width: integer;
begin
  Width:=3;
  DoSomething(Width);
end;

識別子 "DoSomething" の上にカーソルを置いて、Ctrl+Shift+C を押すと、こうなります:

procedure DoSomething(aWidth: LongInt);
begin

end;

procedure SomeProcedure;
var
  Width: integer;
begin
  Width:=3;
  DoSomething(Width);
end;

語彙補完 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の右側にある'...'ボタンをクリックする必要があります。

パッケージ

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

いいえ、なぜなら、それには、Delphiのコンパイラマジック（訳注：Pascalではない部分の特殊な文法）が必要だからです。

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

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

VCL から LCL へ

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

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

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

TControl.Font/TControl.ParentFontについて

VCLでは、コントロールにフォントのプロパティとして、ボールドやイタリック、特定のフォント名と等を使用し、通常はこの値がいつも子へと引き継がれていきます。 さらに、コントロールがいつもParentのフォントを確実にする継承するために、TControl.ParentFontプロパティを提供しています。 OSにウインドウの見え方の設定があるのですが、コントロールのプロパティが常時優先されるということを暗に決めてつけてしまっています。

（訳注：Windowsで画面で大きい文字などが選択できるが、他のデスクトップではもっと多くのことが指定できるものがあるので、Delphiにおいてもシステムフォントを取得することが望ましい、とされる場合もあるが、きっちりデザインが難しくなる。）

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

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

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

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

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

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

これは、現在、どんなControlも以下のTControlの機能、プロシージャ、プロパティを継承していない、使っていない、ということを意味します。

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 unusable -

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

下記の関数も、利用できないか、互換性がありません。

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

TEdit、および、TCustomEditについて

Editコントロールは、LCLもVCLと同等の機能をもっていますが、移植中に、いくつかの気をつけるべき点があります。

1. GUIインターフェースでの制限で、TEdit.PasswordCharはすべてのインタフェースでは、まだ正常に機能しません。入力テキストを隠するために必要とする場合は、代わりに、TCustomEdit.EchoMode emPasswordを使用します。
2. ドラッグ、ドッキングイベントはまだ実装されていません。詳しくは、 Control Dragging/Docking.
3. フォントプロパティは、GUIの統一性のためにたいてい無視されます。詳しくは、 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について

VCLにもLCLにも、TCustomTreeView/TTreeViewのコンポーネントがあります。 ツリー構造化されたデータのリストで、複数のノードや、高度なセレクション、イメージリストなどの機能があります。 多くの機能は同等ですが、すべてのプロパティがまったくおなじではありません。主な相違点は以下です。

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

1. LCLには、 TCustomTreeView.Optionsがあります。これは、コントロールが変更されたときのふるまいと見かけのオプションです。これらのオプションは次の通りです。:
   • tvoAllowMultiselect - 複数のノードを選択できるモードです。eDelphi6のVCLのTCustomTreeView.MultiSelectと同等です。
   • tvoAutoExpand - ノードを自動展開します。TCustomTreeView.AutoExpandと同様です。
   • tvoAutoInsertMark - マウスが上を動くとドラッグのプレビューを更新します。
   • tvoAutoItemHeight - Itemの高さを自動的に調節します。
   • tvoHideSelection - 選択したItemをマークしません。
   • tvoHotTrack - ホットトラッキングをおこないます。TCustomTreeview.HotTrackを有効にするのと同等です。
   • tvoKeepCollapsedNodes - ノードを折畳んだりしたときに、子ノードを維持します。
   • tvoReadOnly - TreeviewをReadOnlyにします。TCustomTreeviewのReadOnlyを有効にするのと同等です。
   • tvoRightClickSelect - ノードをマウスの右クリックで選択状態にできるようにします。TCustomTreeView.RightClickSelectを有効にするのと同等です。
   • tvoRowSelect - 行選択を可能にします。TCustomTreeView.RowSelectを有効にするのと同等です。
   • tvoShowButtons - ボタンを表示します。TCustomTreeView.ShowButtonsを有効にするのと同等です。
   • tvoShowLines - ノードへの線を表示します。TCustomTreeView.ShowLinesを有効にするのと同等です。
   • tvoShowRoot - ルートノードを表示します。TCustomTreeView.ShowRootを有効にするのと同等です。
   • tvoShowSeparators - セパレータを表示します。
   • tvoToolTips - 個々のノードに、ツールチップを表示します。
2. LCLは次のプロパティを追加しました：
   • TCustomTreeView.OnSelectionChange イベント
   • TCustomTreeView.DefaultItems, アイテムのデフォルト設定のためのものです。
   • TCustomTreeView.ExpandSignType ノードの展開、折りたたみの際のサインを決定します。
3. LCLにあるほとんどのドラッグ、ドッキングイベントは動作しません。これについてのより詳細な情報は、前の「ドラッグとドッキングの制御」を見てください。

Messages / Events

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).

Note on handling of custom messages! As of version 0.9.26 (December 2008), way of handling custom WinApi messages (e.g. WM_HOTKEY, WM_SYSCOMMAND) differs from the way of handling these messages in Delphi. At the moment you cannot handle them via message directive or via overriding of WndProc method of the form. The only way to handle them in the form is to hook Windows windowproc by yourself. Read more here: Processing non-user messages in your window

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

See Also

Code Conversion Guide (from Delphi & Kylix)

Compile With Delphi