下図の様に画面にゴミが残るという問題があった。多大な苦労の末にやっと対処できたのだが、読者の参考になるやもしれないので、その経緯を記述しておく。カーソルの描画コードそのものには問題が無いようであった。カーソルを左に移動させ画面を注意深く見ると、古い文字カーソルの右半分が消去されず、ゴミが残っていることがわかった。下図は“う”の位置にテキストカーソルがあった時に、カーソルを左に移動したときに無効化される領域を赤枠で表したもの。“う”の右側が再描画されないので、カーソルの右下部分がゴミとして残ってしまうというわけだ。上図を曇りなき眼で見ると、無効化領域が左にずれているように思えた。ビューポートの原点とかドキュメントマージンとかの問題の様に思えたのである。それがこの問題の原因究明に時間を費やした元凶、犯人が周到に用意したトリックだったのだ。ソースを順に読んで行ってもなかなか判明しなかった。そこで、領域を無効化している部分に目をつけることにした。}上記リストの4行目にブレークポイントを仕掛け、そこで止める。呼び出し履歴を見れば誰がいつどこで領域を無効化しているのか分かるはずだ。プログラムをアクティブにすると必ずここに飛んでくるので、カーソル移動時に領域を無効化している犯人を突き止めることができない。犯人だけをひっかけようと罠を仕掛けたのに、誰も彼もが罠にかかってしまう。選択的な罠でないといけない。無効化領域を記録しているとこだとわかった。カーソル移動の時のみ停止する。犯人のみをひっかける罠が見つかった。そのときの呼び出し履歴をみれば、誰が無効化しているのかがすぐにわかる。コールしてカーソル領域を取得している。プロパティの値を参照しているではないか。コールして、テキストカーソル幅をゼロにしていたのだ。これではテキストカーソル領域が正しく無効化されず、ゴミがのこって当然である。実際には元のテキストカーソル位置の左右数ドットが再描画されている。?と思ったが、その謎はすぐ解けた。なんと下記ソース4行目で、カーソル領域矩形を左右に4ピクセルずつ拡大していたのだ。実は下図のように文字の左端に幅ゼロのテキストカーソル(青色の縦線)があり、その左右4ピクセルが無効化されている、というのが真相であった。文字表示幅が8ピクセル程度だったために、犯人のトリックにまんまと騙され、左にずれているように見えてしまっていたのだ。原因が判明すれば対処は簡単だった。呼ぶ直前にゼロにし、画面描画終わったら直ぐに正しい値に戻してやればいいのだ。ソースは下記のように修正した。}これで、テキストカーソルのゴミが画面に残ることもなく、難事件が解決された後の様にすっきりした。犯人だけがひっかかる罠を作ることが出来れば、犯人をすぐ捕まえられるぞ問題の原因がはっきりすれば対処は簡単な場合が多い。次へ技術文章>qvi。