HTMLエディタを作る(6)(1999/04/14)

さて! いい加減、進展しろよなーと言う事はひたすら聞こえない振りだけど まぁ、実際には全然時間を取ってないんで……1回分の書き込みで約2時間分程度の作業だからね。試行錯誤で時間が過ぎてるのだ。

その試行錯誤のお陰で、何が問題なのかが全容を把握できつつある。何処で何をするべきか……がである。



エディタを普通に使う時に発生する編集のパターンとは、
.文字列を選択している
  1−1.通常入力による置き換え(上書き)
  1−2.クリップボードからのペーストによる置き換え(上書き)
.文字列を選択していない
  2−1.上書き・挿入モード
    2−1−1.通常入力による挿入
    2−1−2.通常入力による上書き
  2−2.クリップボードからのペーストによる挿入
とまぁ、こんな所だろう。TRichEditコンポーネントがサポートするイベントハンドラでは、これら全てを統括的に対処できるものはない。

現時点では、1−1と2−1−1の2つに対応できただけだ。これらはOnProtectChangeの発生によって、崩れるタグの構文を検出したり出来る。これは、このイベントハンドラの因数によって「今から消滅する文字列」を検索できるからである。
また、2−1−2は、1−1に似てるので、現在のモードさえ取得できれば問題なく解決する。

ここで問題となるのは、クリップボードからのペーストだ。この時には複数行からなるテキストを挿入できたりするが、OnChangeイベントでは何処から何処までが挿入された文章なのか判定できない。ペーストの命令時にクリップボードの内容を解析して何文字分のテキストなのか調べられるので、そこから逆算するしかない。

要するに……だ。編集前と編集後のカーソルの位置を記録しておいて、ことある毎に関わる部分の書式を再構成するしかないのである。はっきり言って、力仕事だ。特定の範囲内の色を変えるにしても一々選択してSelAttrivutesであるから……大量にペーストするとベラボーな時間を浪費し、のっぴきならない効率ダウンを招くだろう。

しかし、そうでなければ、再構成のためにあちこちのハンドラに各ハンドラ特有の処理を記述しなければならなくなり、なおかつ多彩な入力パターンに細かく対処した複雑な記述を要求されてしまうだろう。

例えば、「<」や「>」の上にカーソルを置いてDeleteを押下した時と上書きモードでか消えた時とでは、動作が似ていても処理が違ってくる。Deleteキーに他は固有の処理で良いとしても、単なる上書きでは何が押されても発動するイベントハンドラでは厄介な事になるからだ。F1キーを押そうとGキーを押そうと同じハンドラが呼ばれてしまう。大した事ではないのに大袈裟な処理は書きたくない。



究極的には、どの様な入力であれ、修正前の変更範囲と修正された部分との情報を管理する事が出来れば再構成が必要な領域を計算する事が出来るはずだ。

すでにそのための模索を始めている。上手く行けば、バージョンを上げる事が出来るだろう……逆に言えば、バージョンが上がるくらいの変更が必要で、むしろ関係部分は全て書き直しになるだろう。