deletefilehistを使用したときにレジストNo.36441
Roka さん 18/04/05 22:51
 
現在秀丸エディタを「ヒストリの記録を中断」で使用しています。
時々マクロを使用してfilehistcountの個数分getfilehistを使用してファイルのパス
を所得して、existfileでファイルが存在しなかったらdeletefilehistでヒストリを
削除しています。
この時秀丸を終了した後レジストリのHidemaru.dat\FileHistを確認すると、サイズ
が88バイトで1バイト目が58Hで残りがすべて00Hのバイナリデータが途中に残ってい
ることがあります。
また以前ヒストリが100個記録されている状態で同じようなごみが2か所ある状態でde
letefilehistを実行したところ、実行した直後秀丸エディタのファイルメニューでは
そのファイルは削除されましたが、秀丸エディタを終了すると削除されたものがレジ
ストリには反映されず、秀丸エディタを起動しなおすと削除される前の状態に戻って
しまう現象が発生したことがあります。

秀丸エディタ Ver 8.79 32bit
Windows 10 Pro 1709
秀丸エディタ常駐なし

filehistcountおよびdeletefilehistは強調表示に登録されていないようです。




[ ]
RE:36441 deletefilehistを使用したときにNo.36442
秀丸担当 さん 18/04/06 09:15
 

幾つかのパターンを試してみて、うまく再現できなかったのですが、もしこちらでも
再現できそうな手順がわかるようでしたら助かります。

レジストリには"c"という値がありますが、この値はヒストリの数で、これより大き
い番号のレジストリ項目が残る場合がありますが、使われない意味のないものになり
ます。
これのことだとしたら、確実に消すような対策をしてみます。

もしdeletefilehistではなく、setfilehist #n,"";としているようなマクロの場合は、
レジストリに00で埋まる項目ができることがあります。
00で埋まっている項目がある場合は、数に数えられつつもヒストリには表れない項目
になります。
そうだとしたら、そういうものということになります。

再起動後に以前のヒストリ状態が戻るような状況は、おそらくdeletefilehistは直接
的な原因ではなく、普通に使っていても起きる可能性があることだと思います。
最後の秀丸エディタが終了したときにヒストリの情報をレジストリに書きますが、強
制終了したりすると、レジストリに書かれないままになることがあります。
ヒストリに関する操作のマクロ実行後はレジストリに明示的に書くような動作にして
もいいと思います。そういう対策をしてみます。

標準の強調表示では含まれていないものがありました。ご指摘ありがとうございます。
標準のものに追加したいと思います。

[ ]
RE:36442 deletefilehistを使用したときにNo.36443
Roka さん 18/04/06 13:13
 
>
>幾つかのパターンを試してみて、うまく再現できなかったのですが、もしこちらで
>も再現できそうな手順がわかるようでしたら助かります。
>

こちらでも確実な再現方法はまだわかっていません、何かわかりましたらお知らせし
ます。

>レジストリには"c"という値がありますが、この値はヒストリの数で、これより大き
>い番号のレジストリ項目が残る場合がありますが、使われない意味のないものにな
>ります。

ごみが残っている場合でもごみの数を含めて「c」の数は正しかったです。

>もしdeletefilehistではなく、setfilehist #n,"";としているようなマクロの場合
>は、レジストリに00で埋まる項目ができることがあります。

setfilehistは使用していません。

>再起動後に以前のヒストリ状態が戻るような状況は、おそらくdeletefilehistは直
>接的な原因ではなく、普通に使っていても起きる可能性があることだと思います。
>最後の秀丸エディタが終了したときにヒストリの情報をレジストリに書きますが、
>強制終了したりすると、レジストリに書かれないままになることがあります。

この現象が起きたときに何度かマクロを再実行してみましたが、同じ結果でした。特
に異常終了をしている様子はありませんでした。対策が何もなかったのでヒストリを
削除するコマンドですべてのヒストリを削除しました。

以前このマクロはsetfilehistを使用して同じ機能を実現していたのですが、いろい
ろ対応していただいたおかげでこれまで問題なく使用できていました。deletefilehi
stを使用できるようになってマクロは格段にシンプルになりました。以前対応してい
ただいたのも確かごみの問題でした、何か共通点があるかもしれません。

[ ]
RE:36443 deletefilehistを使用したときにNo.36444
秀丸担当 さん 18/04/06 17:06
 

"c"の数は超えていないくて、その可能性は無さそうということで了解しました。
あと、古い形式の20個までの情報も互換性のために見ているのですが、最初の起動時
に、違いがあるとその情報を引き継ぐような処理もありました。
何らかの理由で新旧の情報がずれていると古い情報が引き継がれて出てくる可能性も
あります。

原因となる要素を取り除くために、通常はその処理働かないように修正します。
V8.00未満から上書きバージョンアップした初回の1回だけは変換するようにします。

[ ]
RE:36444 deletefilehistを使用したときにNo.36445
Roka さん 18/04/06 20:54
 
>あと、古い形式の20個までの情報も互換性のために見ているのですが、最初の起動
>時に、違いがあるとその情報を引き継ぐような処理もありました。
>何らかの理由で新旧の情報がずれていると古い情報が引き継がれて出てくる可能性
>もあります。

これまで起きた問題は最初の20個以内で起きていたと記憶していますのでこの可能性
が高いような気がします。


[ ]
RE:36445 deletefilehistを使用したときにNo.36453
Roka さん 18/04/12 17:24
 
>>あと、古い形式の20個までの情報も互換性のために見ているのですが、最初の起動
>時に、違いがあるとその情報を引き継ぐような処理もありました。

たぶんHidemaru.dat\Openだと思いますが、Hidemaru.dat\Openのレジストリを削除し
てから処理を行ったら、ごみが残ったり消したはずのヒストリが戻ったりする現象は
なくなりました。


[ ]
RE:36453 deletefilehistを使用したときにNo.36454
秀丸担当 さん 18/04/12 17:39
 

有力な情報ありがとうございます。
Hidemaru.dat\Openは確かに古い形式のための情報です。
これが関係している可能性は高そうです。
現在のバージョンにおいては、消した後であっても、互換のために古い形式を作成し、
読み込み時に相違があったら参照する可能性があるので、一時的なものかもしれませ
ん。
V8.81β5ではそういうことは無いように修正します。

[ ]
RE:36454 deletefilehistを使用したときにNo.36457
Roka さん 18/04/13 10:44
 
V8.81β5で削除したヒストリが戻ってしまうのが修正されているのを確認しました。
空のヒストリに関しては以前から残っていたものはそのままでしたが、いったんファ
イルヒストリをすべて削除してみたのでもうちょっと様子を見てみます。

[ ]