2010-05-19から1日間の記事一覧

結論として

.NET Frameworkの標準のテキストボックスが高機能になるというのは将来的にもあまり期待できない。素直に誰かのコンポーネントを使うのが一番いいと思う。 私が今回調査した範囲においてAzuki以外には行番号が表示とシンタックスハイライトとが出来て、日本…

Azuki テキストエディタエンジン

Azuki テキストエディタエンジン http://azuki.sourceforge.jp/ 日本人の書いたテキストエディタエンジン。C#から使える。行番号表示、シンタックスハイライトなどが出来る。現在のバージョンは1.55。 ざっと使ってみた感想だが、まずディフォルトのデザイン…

ICSharpCode.TextEditor

SharpDevelopで内部的に使われているテキストボックス。試してみようかとSharpDevelopのソースをダウンロードしてきたのだが、サンプルがVisual Studioでビルドできない。参照設定とかきちんとすれば出来るんだろうけど、Visual Studioでビルドできないプロ…

ScintillaNET

ScintillaNET(→ http://scintillanet.codeplex.com/ )は、世界的に使われているScintillaを.NET用にwrapしたものだ。現在の最新のバージョンは2.2。 早速使ってみた。行番号表示、C#のシンタックスハイライトともに問題ない。 しかし日本語を入力時に入力中…

AlpTextBox

最初、AlpTextBoxという.NET Frameworkで使えるテキストボックスのコンポーネントを使ってみた。vectorで検索するとこれしか無かったのだ。 速度はそこそこ速い。WindowsAPIを直接呼び出して行番号を描画してある。 使ってみてわかったことは行番号を表示す…

現代のテキストボックスのあるべき姿とは?

こういう大貧民的プログラミングの視点で捉えると、.NET FrameworkのTextBoxは、WindowsのEditBoxの薄いwrapperで、メソッドが十分に用意されておらず(現在のキャレットの存在する行番号すら取得できない)、これでは十分なパフォーマンスが出るとはとても言…

25年前のテキストエディタの設計技法

テキストエディタなので行の挿入・削除などが頻繁に行われるわけだが、行の挿入や削除によって大きなメモリブロックのコピーをするわけにはいかない。ゆえに、各行を双方向linked listで持っておいて削除・挿入時にメモリブロックのコピーは極力発生しないよ…

25年前のテキストエディタ

もうかれこれ25年ぐらい前になるが、当時のパソコンでもテキストエディタをきちんと作るのは大変だった。オールアセンブラで書かなければならないということに加えてターゲットがZ80 4MHzとかなので無駄なメモリコピーなどを限りなく省略しなければならない…

Visual Studio 2010のword wrapの遅さ

どれくらい遅いかというと↓これくらい遅い。 Visual Studio 2010のword wrapの遅さ(本の虫) http://cpplover.blogspot.com/2010/04/visual-studio-2010word-wrap.html この分ではVisual Studio開発チームに出来のいいテキストボックスなんて期待するのは土台…

TextBoxに関する覚書のすべて

自作のソフトでテキストの編集が出来るようにしたかったのだが、普通のテキストエディタのようにundo/redoが出来るようにしたり、範囲選択+tabだとか、自動インデントとか行番号表示だとかそういったものをサポートしようと思うと結構大変だ。 .NET Framewor…