Code Conversion Guide/ja
│
Deutsch (de) │
English (en) │
español (es) │
français (fr) │
日本語 (ja) │
português (pt) │
русский (ru) │
slovenčina (sk) │
このページでは、すでにDelphiやKylixで書いたコードを Free PascalコンパイラやLazarus IDEで動くようにするための方法を説明します。 LazarusとFree PascalコンパイラはDelphiやKylixと同じ方向性をもっていますが、LazarusやFree Pascalは、それらのクローンではありません。 沢山のライブラリコールや使い方に違いがあります。そして、いくつかの場面において、FPCは拡張されており、また、より正しい文法を要求することがあります。
Lazarus For Delphi Users/ja を見て、機能的な違いを確認してください。
このガイドの目的は、Delphiの既存のコードをLazarusに変換するときに、よく出会う特徴的な違いを、きちんと文書化することです。
この文書はWikiの知識ベースに置かれていますので、だれでも問題に出会ったときに他の人にも知らせることができるよう、拡張できます。
変換時のコンポーネントやライブラリの選択
変換するコードの場所を見つける
ネット上には、変換すればFPCやLazarusで使える、沢山の利用可能なコードがあります。たとえば、このページPage Of Code Sitesがスタートとなるでしょう。他のもっといいコードサイトのURLなどを知っていれば書き加えてください。
TurboPowerソフトウエア社は、最近彼らの商用製品をMPLのライセンスの元でリリースしました。使えるパッケージは、http://sourceforge.net/users/tpsfadmin/ ここ]にあります。 作業が重複するのを避けるため、変換されたパッケージはComponents and Code examplesページにあります。 もし、あなたが変換したパッケージや、変換中のものがあれば、Current conversion projects ページに書き加えてください。
ライセンス
Licenses for existing code range from freeware/public domain to restrictive versions that prohibit modification, re-distribution and commercial use. Before converting any package, it's a good idea to examine its licensing and make sure it's going to be compatible with Lazarus and the Free Pascal Compiler. License selection is especially important with components since dropping one on a form can impose an unwanted or incompatible license on an entire application.
When converting components, please respect the wishes of the original author and retain all copyright and licensing headers along with email addresses and url's. It's courteous and often useful to inform the author that their component is being converted... especially if the component is under a restrictive license. New interest in an old or forgotten component can sometimes inspire authors to revise their original and overly restrictive licensing.
In general, Public Domain (freeware), and the LGPL/MPL are the the most flexible for distributing components. For more information, the Open Source Definition is a good place to start. There are also several comparisons available to help clarify how the various types of licenses work and what impact they'll have on code they're linked to. Search for "open source license comparison"
依存関係
変換をはじめる前のもう一つのステップは、それらのコードが、利用できないか、簡単には変換できそうもない他のパッケージと深い依存関係をもっていないことを確認することです。 いくつかのフリーウエアはいまや使われないような利用できないパッケージや、あるいは適切でないライセンスをもつパッケージと結合しているか、拡張されていることがあります。
コンパイラの問題
下記を見てください:
プラットホームとOSの問題
LazarusとFree Pascal Compilerはクロスプラットホームであり、クロスプラットホームアーキテクチャ開発ツールです。DelphiのほとんどのコードはWin32でのインテルCPUで実行されるように設計されていることと比較してみてください。 もし、あなたのコンポーネントが多くのWin32に特化したコードを使っていれば、すこしでもプラットホームに依存しないようにしてみることをお勧めします。 しかし、多くのWindowsに特化したコードをつかっているからといって、LCLへの挑戦をためらわないで下さい。本当にLCLはすばらしい機能を提供しています。
変換をおこなう
変換するプロジェクトのためのLazarusの環境を設定する
テストプロジェクトを作成する
- サブディレクトリ(例: convertdir)に、変換されるほうのコードを置く。
- Lazarusを起動する
- File->Save All でthe convertdirのサブディレクトリに保存する。 プロジェクト名に意味の名前を付ける。デフォルトユニットの名前をつけるのは好きにしてよい。
- converdirで、変換するメインとなるユニットを開く。
- それをプロジェクトに加える。: Project->Add Active Unit
- Run Tools->Quick Syntax Check をするか、 Run Build All で開始してみる。
最初に目を向ける事柄
- 1.0.x系のコンパイラでは、ファイル名は大文字小文字を判別します。もし、このバージョンで作業していたら、全ファイル名を小文字にしてください。そうしなかったら、 "File not found" エラーになります。
Lazarus上でのDelphi VCL, Kylix CLXのソース
DelphiやKylixのソースを変換しているとき、特定の機能の関数がなにをやっているか、宣言を探すことは、よく役に立ちます。LazarusのIDEは、DelphiやKylixのソースコードを解析できます。これをするためには、検索パスとコンパイラ設定をきちんとおこなわなくてはなりません。これらは、Environment->CodeTools Defines Editor->Insert Templateで簡単におこなうことができます。
変換に関する問題と解決方法
LazarusでのDelphi / Kylix ファイルとの対応
Delphi / Kylix | Lazarus | Description |
.pas
.dfm / .xfm .dcu / .dpu .dpr (main project file) .res .dof / .kof --- --- --- |
.pas, .pp
.lfm .o .lpr --- --- .lrs .lpi (main project file) .ppu |
Pascal unit file
Form data file Compiled unit file Project file Resource file Project options file Lazarus resource file Lazarus project information file FPC unit description file |
Delphi プロジェクト/フォーム/ユニットを Lazarus に変換する
.dprファイルを.lprへcopyするか、名前を変更します。
ディレクティブをコメントアウトするか、削除して、
か
ディレクティブを.lprファイルへ加えます。
Toolsメニューの中には、変換に便利な"Convert Delphi Project to Lazarus Project"という項目があり、lazarus IDEは変換を手助けします。 この項目を実行すると、.dprファイルを.lprに変換するかどうか聞きます。そして、.lpiファイルを作って、全てのユニットを変換します。多くのすでにあるDelphiフォームは、Lazarusが .dfmを.lfmフォームに変換します。これは、Toolsメニューの"Convert DFM file to LFM"という項目で出来ます。ファイルダイアログが立ち上がり、dfmファイルを選択すると、自動で変換をおこないます。
もしフォームであろうがなかろうが、全ユニットを変換する場合、Lazarusの"Convert Delphi unit to Lazarus unit"では次のようにおこないます。
- includeのファイル名とuses部分の大文字小文字を修正します。
- .dfm ファイルを .lfm ファイルに変換します。(currently without content check, just format)
- 空の.lrs ファイルを作成します。 (中身は後で生成されます。)
- {$mode delphi}ディレクティブを追加します。
- windowsユニットをLCLIntfに置き換えます。
- 必要であれば LResources ユニットを付け加えます。(もし unit.lrs が使われている場合 uses LResourcesをimplementation 部分に入れます)
- variants ユニットは削除します。
- {$R *.dfm}ディレクティブは削除します。
- initialization 部分に {$i unit.lrs}ディレクティブを加えます。
この方法でほとんどのユニットをDelphiフォーマットをLazarusフォーマットへ迅速に変換できます。この方法は、正当性のチェックや、自動的な文法の変換をするものではありませんが、いろいろなウイザードがそのようなことや変換などををするので、文法上の変換したり、他のユニット名を変換したり、コンポーネントやコントロールの違いで、dfm/pasファイルを手で変更する必要はありません。
正しいコンパイラモードを選択する
Free Pascalコンパイラには5つの異なったパスカルモードがあります。たとえば、TPはTurbo Pascal互換モードですが、これをつかってTurbo Pascalのユニットをコンパイルできます。また、DELPHI互換モードがあり、既存のDELPHIコードの変換を簡単にします。Lazarusにおいては、DELPHIモードよりもOBJFPCモードをお勧めします。このモードはほとんどDELPHIのモードと似ていますが、DELPHIの文法よりもあいまいさがすくなくなっています。 下記に重要な点を示します。
モードはコマンドラインか、もしくは、ソースコードの最初に指定します。もしソースを変更する必要が無いなら、コマンドラインを使うほうが良いですが、他の諸々を指定しなくてはならない場合は、使わないほうが良いでしょう。
ほとんどのDelphiのユニットは下記のようにすることでFree Pascalでコンパイルできます。
{$IFDEF FPC} {$MODE DELPHI} {$ENDIF}
ユニット名の直後におきます。
Free Pascalのモードについて、詳しくは、Free Pascal Documentation をご覧下さい。
クロスプラットホームで考慮すべきこと
- インラインアセンブラは、大抵の場合インテルアーキテクチャに依存しているので問題を引き起こします。ある開発者たちは、Pascalでプロトタイプを書いて、IFDEFでアセンブラで最適化しています。幸いなことにTurboPower社では、そのように多くのコードを書いています。もしこういう場合を見つけたら、IFDEFでPascalに戻すようにしてください。
- BIOSの特定のデータエリアを参照しないでください。コードが何をしようとしているのか見つけて、クロスプラットホーム環境ではどのように書いたらいいか、挑戦してみてください。
(訳注:おもにシリアル通信やパラレルの制御などで、特定のIOポートやハードウエアを制御していることがあるが、APIやエスケープファンクションに置換することができるが、そのようなものまでクロスプラットホームにできるようにPascalの標準IFが準備されているわけもないので、ある程度OSには依存してしまうだろう。)
- 固有のプラットホームのためのIFDEFで囲むことなく、プロセッサの特殊な機能(IntelのTSC命令のような)を使わないでください。そして、別のハードウエアの環境のために、代わりとなる方法を提供できるようにしてください。
- OSに依存するコードが必要なばあい、IFDEFを使ってください。下記にそのマクロのリストを示します。
便利なコンパイラ変数
異なったシステムで異なった動きをするコードを書くために、
指令を使うことができます。
- {$IfDef LCL}
この値はLCLパッケージを使っているときに定義されています。LCLとDelphiの両方で動くコードを書くときに便利です。
- {$IfDef LCLGtk},{$IfDef LCLWin32},{$IfDef LCLQt}, ...
これらの値は、LCLが特定のwidgetsetで使われているときに定義されています。 LCLが特定のプラットホームで動くときのコードを書くときに便利です。
- {$IfDef FPC}
この値はFPCコンパイラ定数を使っているときに定義されています。FPCとDelphiの両方で動くコードを書くときに便利です。
- {$IfDef Unix},{$IfDef Win32}, ...
FPCによって現在のターゲットOSのために定義されています。Delphi(やKylix)は"Linux", "Win32" and "MSWindows"を定義します。Free Pascalはさらに多くのプラットホームで動作し、一般的に使われることが推奨されています。 たとえば、LazarusのプラットホームであるLinux、FreeBSD,NetBSD、OpenBSDでは"Unix"が定義されています。同じソースコードが、KylixでもLazarusでも動くようにするためには、
{$IfDef Linux} {$Define Unix} {$EndIf}
などとしてください。
もっと詳しいことは、こちらをみてください。Free Pascal Documentation.
失った識別子を見つける
Delphi VCLと、LCLを比較すると構成の方法に違いがあります。 もし、"not found"というコンパイラエラーが、主要なクラスや識別子で出たときは、多くの場合異なったユニットにあります。
完全なクロスリファレンスは、lazarus/docs/xml か LCLのサブディレクトリをgrepしてください。
たとえば、一般的によく使われるTButtonのDelphiのコードは、Lazarusではbuttons.ppというユニットにあるので、コンパイル時にエラーになります。 次のコマンドは、正しいユニットをLazarusのソースディレクトリから高速に見つけ出します。
grep -in ' tbutton =' lcl/*
LazarusとDelphiの主要なユニットの違い
このトピックに書き加えてください。
- Windows->Interfaces, LCLIntf, LCLType, LCLProc, VCLGlobals, ...)に置き換えます。
LCLはWindowsに限ったものではないので、DelphiのWin32APIに直接アクセスするためのWindowsユニットは、インターフェースに抽象化されてLCLIntfユニットからアクセスするようになります。 覚えておいて頂きたいことは、Lazarusはwin32をエミュレートするのではないので、多くの関数が欠落していたり、Win32と同等な働きをしない関数があります。これらの関数はDelphiとの互換性だけのためにあり、とにかく移植するだけのためにあります。LCLは多くの型を利用し、LCLTypeやVCLGlobalsを必要とします。LCLProcは、FreeThenNilのようなDelphi5以降で導入された便利ないくつかの関数や、コントロールのばめに余分なアンパーサンドを取り除くDeleteAmpersandsのようなものを含みます。 Interfacesユニットは、適切なwidgetsetを初期化するための.lprファイルをインクルードするために必要です。
- Messages->LMessagesに置き換えます。
Delphiでは、TControlメッセージ(Win32イベントコールバックでは、WM_CALLBACK形式になっています。)とそれらに関連するメッセージはMessageユニットにあります。 LCLでは、これらの型やメッセージ、構造体などの定義は、LMessagesユニットにあります。大抵の場合、WM_MOUSEENTER は LM_MOUSEENTER に、TWMMouse は TLMMouseに、といった具合に、WMをLMに変更されています。
- Graphics, Controls->GraphTypes, GraphMath, Graphics, Controls に置き換えます。
(グラフィックスのための)いくつかの事柄を簡素にしたり、ユニット間の複雑さの連鎖を断ち切るため、GraphTypeと呼ばれる共有ユニットで、いくつかの型が抽象化されました。それは、Delphiの中では、GraphicsやControlで定義されていたものを含んでいます。たとえば、PanelのbvNoneなどの定義などで、そのため、GraphTypeはインクルードしなくてはなりません。また、Delphiと互換性はありませんが、GraphMathという便利な機能をもつユニットがあります。それは、小数点の位置をもてるTFloatPointや、ベジェ曲線、直線、円弧などを扱えます。また、TPointやTRectの演算子オーバーロードをおこなっていますので、 点の位置を加算するのに Point1 := Point2 + Point3 としたり、 2個の矩形を比較するのに、 if (rect1 = rect2) then ... と書くことができるようになります。
- Mask->MaskEdit に置き換えます。
TMaskEditのためのユニットは、多くのバージョンのDelphiのようにMaskという安直なものではなく、よりよい名前を考えると、[MaskEdit|] と呼んだほうがよいでしょう。
- StdCtrls->StdCtrls,Buttons に置き換えます。
多くのバージョンのDelphiでは、TButtonはStdCtrlsにありますが、TSpeedButtonやTBitBtnはButtonsユニットにあります。LCLでは、一貫性と簡潔性から、全てのボタンの定義はButtonでおこなっています。これは、includeするのにいいアイディアだと思いますよ。
Delphiのプロパティとメソッドの違い -> FPC/LCL
- LCLではTBitmapにCanvasがあります。
文法上の違い
このトピックに気づいたものを加えてください
で、Delphiと互換性をもてるよう、いくつかの文法上の許容をしても、FPCの文法上の厳密さから、プログラムの構文の変更が必要になることがあります。その理由は、FPCでは、DelphiとLCLの両方で共有されるソースであっても、なるべくなら、
を用いるよう、高く推奨されているからです。
これは、単により良いコーディングの習慣をつけるということと、Delphiモードは必ずしも(文法が)正確ではなく、または、いくつかの例では、Delphi互換コードはコンパイルされてもFPCほど機能的でないためです。このため、すべてを厳密に要求するわけではありませんが、次のことは考慮してください。
- イベントハンドラ関数を登録するときは、関数の前に"@"をつけてください。
(訳注:@は、後に続く変数や関数のアドレスを明示的に示します。関数の前につけることで、関数のエントリアドレスを得ることができ、それをイベントハンドラを示す変数(=ポインタ)に代入するコードを書きます。関数の呼び出しと、参照を明確に区別することができます。)
たとえば、ボタンのイベントを手動で登録するには、次のようにおこないます。
Delphi | FPC |
begin
if not Assigned(MyButton.OnClick) then
MyButton.OnClick:= SomeFunction; //@ not required
//more code...
end ;
|
begin
if not Assigned(MyButton.OnClick) then
MyButton.OnClick:= @SomeFunction; //@ IS required
//more code...
end ;
|
- イベント変数で、関数をコールするには、次のような文で書きます。: theprocname()
Delphiの文法では、イベント変数に関して、関数の結果を得るのと、変数を区別する方法がありません。しかし、FPCではそれができます。そのために、関数として呼び出す場合は、パラメータが無くても、括弧をつけてください。 たとえば -
Delphi | FPC |
With (SomeObject) do begin
If Assigned(OnMyCallback) then
OnMyCallback; //parenthesis not required
end ;
|
With (SomeObject) do begin
If Assigned(OnMyCallback) then
OnMyCallback(); //parenthesis required
end ;
|
- When accessing values in a pointer to a record you must dereference first
- レコードポインタで、値をアクセスするときは、(^)をつけて逆参照しなくてはなりません。
Delphiの文法では、ポインタの逆参照記号は必ずしも必要とされません。実際に、ポインタはレコードやオブジェクトそのものとして扱うことができます。FPCでは、逆参照記号を付ける必要があります。 たとえば、
Delphi | FPC |
Function GetSomeValue(ARecord: PMyRecord)
: Integer;
begin
If Assigned(ARecord) then
Result:= ARecord.SomeValue
else
Result:= 0 ;
end ;
|
Function GetSomeValue(ARecord: PMyRecord)
: Integer;
begin
If Assigned(ARecord) then
Result:= ARecord^.SomeValue
else
Result:= 0 ;
end ;
|
- When accessing chars of an indexed string Property of an object, it must be enclosed in parentheses
- オブジェクトの配列化された文字列プロパティのキャラクタにアクセスするときは、括弧でくくります。
Delphiでは、文字列のプロパティの個々のキャラクタにアクセスするときでも、constやvarのように直接扱うことができますが、FPCでは常時そのことが可能ではありません。特に、配列化されたプロパティでは不可能です。この場合、区別するために、括弧でくくることで可能です。 この方法はいつでも正しいとは限りませんが、とにかく、良い習慣だといえます。
たとえば
Delphi | FPC |
Type TSomeComponent= class (TComponent)
//More code...
Published
Property MyString: String index 3
read GetMyString;
//More code...
End ;
var
MyChar: char;
begin
If Length(MyString)> 2 then
//no parenthesis needed
MyChar:= MyString[3 ];
//More code...
end ;
|
Type TSomeComponent= class (TComponent)
//More code...
Published
Property MyString: String index 3
read GetMyString;
//More code...
End ;
var
MyChar: char;
begin
If Length(MyString)> 2 then
//parenthesis sometimes needed
MyChar:= (MyString)[3 ];
//More code...
end ;
|
- 変数や関数のポインタは型キャストをおこなって、実際の型として扱う必要があります。
時々Delphiでは、型なしポインタ変数としてオブジェクトを示すことがあります。 複雑な状況では、これは、特に大きなコンポーネントパックなどで、多くのユニット間の循環参照を解消するために、一般的な手法です。Delphiでは、オブジェクトを期待している関数にこの型なしポインタを型キャストなしに送ることができますが、FPCでは型キャストが必要です。
たとえば、 -
Delphi | FPC |
Unit 1
Type TSomeObject= class (TComponent)
//More code...
End ;
Procedure DoSomething(Value: TSomeObject);
Function GetSomeObject: TSomeObject;
Unit 2
Type TSomeComponent= class (TComponent)
//More code...
Published
SomeObject: Pointer;
//More code...
End ;
Application
var
MyComponent: TSomeComponent;
begin
MyComponent.SomeObject:= GetSomeObject;
//More code...
DoSomething(MyComponent.SomeObject);
end ;
|
Unit 1
Type TSomeObject= class (TComponent)
//More code...
End ;
Procedure DoSomething(Value: TSomeObject);
Function GetSomeObject: TSomeObject;
Unit 2
Type TSomeComponent= class (TComponent)
//More code...
Published
SomeObject: Pointer;
//More code...
End ;
Application
var
MyComponent: TSomeComponent;
begin
MyComponent.SomeObject:= Pointer(GetSomeObject);
//More code...
DoSomething(TSomeObject(MyComponent.SomeObject));
end ;
|
リソース
Delphiのリソースファイルはwin32形式であり、Lazarusのものと互換性がありません。 ですから、Lazarusで使うためには、再生成してコンパイルします。Lazresというツールが、lazarus/toolsサブディレクトリにあります。もし、Lazarusのソースをダウンロードしているなら、まず、次のようにコンパイルします。
- cd lazarus/tools
- make install
リソースをアプリケーションに追加するために:
- lazres myresource.lrs mypix.xpm anotherpix.xpm
- Uses節に LResources ユニットを追加してください。
- .lrs ファイルをinitializationブロックにインクルードするようにしてください。
例:
function TForm1.LoadGlyph(const GlyphName: String ): TBitMap;
begin
Result:= TPixmap.Create;
Result.LoadFromLazarusResource(GlyphName);
end ;
//More code...
begin
Speedbutton1.glyph:= LoadGlyph('mypix');
//More code...
end ;
initialization
{$I unit1.lrs}
{$I myresource.lrs}
end .
|
DelphiやKylixプロジェクトをLazarusに変換する他の方法
- .dfmや.xfmファイルを.lfmファイルにリネームするかコピーします。(初期のバージョンのDelphiはテキストベースの.dfmファイルを生成しません。変換ユーティリティが \binフォルダにあれば、まず.dfmファイルを変換します。)
- .dprファイルを .lprファイルにリネームするかコピーします。
- .lprファイルに適切な変更をおこないます。
- {$mode delphi}{$H+} か、 {$mode objfpc}{H+} 指令を加えます。
- 'Interfaces'をuses節に加えます。
- {$R *.res}や相当する指令をコメントアウトするか、削除します。
- すべての.pasファイルに必要な変更をおこないます:
- {$mode delphi}{$H+} か、 {$mode objfpc}{H+} 指令を加えます。
- uses節に'LResources'を加え、もしフォームにボタンがあれば、さらに'Buttons'も加えます。
- {$R *.dfm}や{$R *.xfm}指令をコメントアウトするか、削除します。
- 'Initialization'セクションをユニットの最後に加え、その中に{$I unitname.lrs}指令を入れます。
- [プロジェクト]->[ファイルから新規プロジェクト]を選択します。
- .lpr ファイルを選択します。
- "新規プロジェクトを作成"ウインドウで、'アプリケーション'を選択します。
- [プロジェクトの構築]を実行して、更に、適切なコンパイルのために必要な訂正をおこないます。この時点で、.lpiファイルが自動的に生成されます。
'Error reading Form'メッセージを受け取るかもしれませんが、続行する場合は'読み込みを続行'を押し続けてください。
- 全て保存すると、Lazarusプロジェクトが完成します。:-)
ヘルプを見つける
もし、Lazarusへの移植中に解決できない問題にぶつかったとき、助けとなるWEBが沢山あります。 純粋に、Object PascalとFPCの問題である場合、FreePascalの文書から調べてみるのが良いでしょう。Documentation by Michaël Van Canneyt and Florian Klämpfl. さらに、Lazarusが中心の問題であれば、Lazarusに関する文書をLazarus-CCR 知識ベースMain Pageで、 探すのがよいでしょう。 最後に、質問を mailing lists for the Free Pascal Compiler や、FPC forumsへ投稿することができます。沢山のエキスパートがこれらのメーリングリストに登録しています。 他の検索やオンラインの知識データベースなども、問題解決やあたしい技術を学ぶ上で大変役に立ちます。 Tamarack Associates search では、Borland usenet archivesに特化した高速な検索エンジンを使うことができます。operates a Mer Systems Inc. engineでは、同じような検索を提供しています。 もうひとつ、外部の情報源として、search では、Earl F. Glynn's Computer Lab and Reference Libraryの検索を可能にしています。
コンポーネントをパッケージしてリリースする
コンポーネントのLazarusパッケージを作る
あなたが変換したコードの中に特に一つ以上のコンポーネントがある場合、、パッケージを作って配布すると、他の人がインストールするのが簡単になります。 Mattias Gärtner が概要を Lazarus Packagesで書いていますので、パッケージを作成する場合は、一度事前に読んで下さい。
文書
このサイトの目的と、Wiki形式で運用している理由は、より簡単に、速く、本格的なドキュメントを作成することです。Wikiは、あなたが投稿したり、修正した結果をすぐに反映します。
Lazarus-CCRのwikiを使って、見栄えの良い文書を作ることは簡単です。wikiのマークアップを使ったことがなければ、Sand Box で試しに色々と使ってみて下さい。
コードリリースページを作る
コードリリースページは、あなたの製作したコンポーネントのライセンス、想定している動作プラットホーム、状態(α版、β版、安定版)、どこでダウンロードできるか、著者、サポート情報....などの生きた情報を、ダウンロードしようとしている人たちに提供します。
ブラウザであなたの作ったコンポーネントのコードリリースページを作る方法を紹介しましょう。
- Release new componentへ行きます。
- あなたの生成したコンポーネント名を入力し、Create Articleを押します。
- テンプレートに入力し、保存してください。
- Components and Code examplesを編集し、"Released Components"セクションに新しく作ったページのリンクを加えてください。そして保存します。
コンポーネントをサブミットする
もし、プロジェクトのリリース技術者であれば、あなたのコンポーネントをSourceForgeファイルリリースシステムにアップロードして、リリースパッケージのリストに含めてください。そうでなければ、我々プロジェクト管理者(Tom Lisjac or Vincent Snijders)に送っていただければ、リポジトリに加えます。
もし、コンポーネントの開発を続ける必要性があるなら、CVSにおきます。そうすれば、それにアクセスし続けることができます。(訳注:現在はCVSではなくsub versionで管理している)
Contributors and Changes
This page has been converted from the epikwiki version.
- Initial version by Tom Lisjac and Mattias Gärtner - 9/22/2003 VlxAdmin
- Moved Getting help from the main page. T. Lisjac - 9/24/2003 VlxAdmin
- Added documentation templates, procedure and links. 9/25/2003 VlxAdmin
- LCLLinux was renamed to LCLIntf, Jesus Reyes, 9/27/2003
- added more information on Unit changes, AndrewJohnson 9/27/2003
- Updated Syntax differences, including some examples, AndrewJohnson 9/27/2003
- FPC 1.0.x doesn't support interfaces, Vincent Snijders 9/28/2003
- Fixed some of the examples per new WikiWord definition, 9/28/2003 VlxAdmin
- Made code more consistant to remove last accidental Pascal WikiWord definitions, AndrewJohnson 9/27/2003
- Use tables for code examples for nice blocks, and easy side by side view of Delphi->FPC differences, AndrewJohnson 10/17/2003
- Use pascal stylesheet to make example code more readable, AndrewJohnson 10/18/2003
- Added 'Another method to convert a Delphi or Kylix project to Lazarus' section , George Lober, 2/17/2006