部品を選定した際の記録を簡単にまとめたものです。2009年8月1日追記。結局、テキストエディタエンジンを自作しました。オープンソースプロジェクトをホストして開発しています。ご興味があれば、ご参照ください。求められる機能はユーザにより異なります。部品として利用できるようコンパクトにまとまった物がほとんどありません。そのコア部分だけを取り出して他プロジェクトにそのまま流用するのは難しい場合がほとんどです。度重なる機能追加により部品としての可搬性が失われやすいのでしょう。それにあたって次のポイントを重要視しました。つの候補が見つかりました。次にその候補を記します。開発されている、世界的に有名なテキストエディタ部品です。言語依存もありません。日本語の入力や表示も問題ありません。単語補完やコードの折り畳み機能、ブックマーク機能もあります。系のものに近いライセンスになっています。テキストエディタ部品です。エディタ部品だけ取り出して改造できます。日本語の入力も表示も問題ありません。単語補完やコードの折り畳み機能、ブックマーク機能もあります。著名なプログラミング用テキストエディタでの採用実績があります。利用可能だと思います。TEditor和製エディタコンポーネントです。非常に多くのエディタで利用されている実績があります。和製ですので日本語の利用もまったく問題ありません。単語検出ロジックを自前実装しなければ使いにくくて困る事です。行末までカーソルが飛んでいってしまいます。いえ、これは自前で単語処理を実装すれば良いだけの話なので大きな問題ではありません。これが意外に厄介です。内のインデックスはバイトインデックスであり文字インデックスではありません。いう処理を考えましょう。プログラムから使いますから文字インデックスで指定するのが自然です。文字目が何バイト目に相当するか計算しなくてはなりません。これはかなり非効率に思えます。扱いにくくなる事は間違いありません。上にネイティブなウィンドウを配置する場合の問題です。世界におけるイベントは親ウィンドウへ投げられた通知のメッセージを処理する事で扱います。メソッドをオーバーライドしてその通知を解釈すればイベントは扱えます。通知の処理を考えるとネイティブなウィンドウをそのまま置くだけではこのような形にできません。あらゆる面で非常に扱いにくくなります。このクラスをそのネイティブなウィンドウと同等なものとして扱うようにします。プロパティが反映されるようになります。的に使いやすくなります。コントロールとまったく同じ使用感でそのネイティブウィンドウを操作できます。同一ウィンドウ内のボタン等に設定されたニーモニックと同じキーを押すとそちらにフォーカスが奪われてしまう等の問題が起こります。この問題を解決するのは大変ですが、不可能ではありません。採用する場合の問題は二点です。場合と同様に日本語の単語検出ロジックを自前実装しないと、という話です。二点目は非常に高機能であるためか部品としての機能を一手に公開するインタフェースが無い事です。機能ごとに異なるメンバオブジェクトへアクセスする必要があるという事です。とっつきにくく、そして操作が面倒というのが問題です。配置した場合、現在選択しているテキストを取得するには次のように長い文を書く必要があります。textEditorControl.ActiveTextAreaControl.TextArea.SelectionManager.SelectedTextあるいは現在入力されているテキストの長さを取得するには次のようになります。オブジェクトにアクセスします。オブジェクトにアクセスします。クラス階層のどこに何があるのかすら最初は分からないため苦労しました。(しかしこの部品、カーソルの挙動が少し気持ち悪い。個人的には修正して使いたい。採用する場合の問題は、プログラミング言語の壁です。開発環境を持っていません。買わずに開発する方法があるかもしれない。的に操作するのかも調べる必要があります。この時点でほぼ諦めが入っていました。プログラミング言語の壁があるため採用する気は最初からほとんどありません。そのソースコードを使って第三者が開発を行う場合は当然シェアウェア料金を払う必要があります。