ugnagブログ

ところが、新しい問題が発生。

というか、気が付いてはいたのだが、大丈夫だと思っていた。だが、だんだん気になってきたので直すことにした。

それは、次のような現象。

変換する範囲を選んだ後、条件設定をするためにテキストエリアからフォーカスを外すと、選択範囲の反転表示が解除される。

フォーカスが外れたときに選択範囲がわからなくなるのは、やっぱり使い難いと思い始めた。


簡単に直るかと思ったら、これが意外と大変。

当初は、テキストエリアで使っているJTextAreaを、JTextPaneに変えて、フォーカス処理すればいいだけだと思っていた。

しかし、いざ修正してみるとJTextAreaで実装されている機能でJTextPaneには無いものがいくつか有り、アイテム番号変換の処理ではそれが不可欠。

具体的には、オフセット位置と行位置を相互に変換する機能や、行数のカウントなどの機能なのだが、これを自分で作るところから始めなければならなくなった。

しかも、コード中ではJTextAreaに対し直接メソッドを実行していたため、変数をJTextPaneに変えるとコンパイルエラーが続出。

JTextComponentAnalyzerというクラスを作り、必要な機能はこれを通して実行することにした。

この実装がなかなかうまくいかず、四苦八苦。


やっとなんとかなり、その上でJTextAreaをJTextPaneに変えた。

そこまでの段階をテストし問題が無くなって初めてスタートラインに立ったようなものだ。

とはいえ、スタートからゴールまでの距離は短い。

フォーカスが外れたときには選択範囲の背景色を変更し、フォーカスを受け取ったときには全範囲の背景色を元に戻す。

これだけだ。

最初はこれだけだと思ったので手を出したのだが、結構大変だった。。。。


やってる間に、掲示板にPCEのトラブルのメッセージが入ったという通知は来るし。。。

そいうえば、このトラブルはちょっと考えられないものだ。

というのも、このトラブルはXMLファイルのパース時に不正な文字を見つけたというものなのだが、XMLファイルの書き出しはXMLパーサーにまかせているのでそんなことは起きないはずだ。

アプリケーションでどんな文字を用意しようと、そのままでは問題のある文字が含まれていた場合、書き込み時にXMLパーサーが適当なものに変換し出力する。

そして、読み込み時には変換されていたものを、やっぱりXMLパーサーが元に戻す。

アプリケーションで、直接XMLの読み書きをしているのならともかく、完全にXMLパーサー任せなので、なぜそんなことが起きたのか理解できない。

さらに、XMLパーサーに対する操作も、アプリケーションで直接やっている訳ではなく、何度も実行済みのクラスが行っている。

ようするにアプリケーションでは、DOMの構造を作ることしかやっていないのだ。


詳しいことは、実際にどんなファイルを読み込んだのか、内容をみてみないと判断がつかないが、今のところ原因はまったく見当もつかない。


バグだったら、修正しだいのアップになるかな。