だから、検索した結果のファイルを全部削除したい、というのはちょっち面倒な操作になる。検索して、検索結果のファイルを選択することでそのディレクトリに移動、削除、また検索…、の繰り返し。[DFって何?][日記][コマンド一覧][関連リンク][予定表][他のファイラー][逃げ帰る]
DF、Vectorにて公開。
メインウインドウでIMEが使える利点が無いので(っていうか、害ばかり)オフにする。
でも、ImmAssociate()ってNT3.5で使えたっけ。よくわからないのでダイナミックロードする。
今までは、メインウインドウもサブウインドウも同じウインドウプロシージャを使って、ウインドウプロシージャの中でどちらのウインドウから呼ばれたのかを判定していた。
無駄に思えたのでSetWindowLong()でそれぞれのウインドウプロシージャを書き換えることにする。
若干コードサイズを小さくすることができたが、実行ファイルには影響無し。くぅ。
ここまで来るとあまり意味がないかも。ただ、あまり動作確認をしていなかったりして。
若干実行ファイルのサイズが増えてしまった。現在76,800バイト。
fで、メモリ取得量の計算を誤っていた部分があったので修正。FGALTLAではまだ未公開だったのでキャンセルできたがFWINALは間に合わなかったのでバージョン番号を上げた。
なんかDOSファイル名が正しく表示されていないような。
って他人事じゃないじゃん。とりあえず修正する。
なんか、もうダウンロード数30いってるし。なんか、バグフィクス版、アップロードしにくいなあ。
とりあえずファイル検索機能をもう少しなんとかしたいとか。そのためにファイルリスト生成部分の構造を作り替えたりしたのだが。
なんというか、すでにFIVAの液晶が暗すぎてコーディングする気力が失せてしまう。照明を暗くしないと字すら読みにくい。最近誤変換が多いのは多分、このせい。間違ってても気付かないのだ。読めないから。
ほんのちょっち書き直す。やはり黒でびしっとくくったほうが絵が締まってみえる。
マウスオペレーションで終了させる時に確認無し終了(即座に終了)することはできないのかと訊かれる。できない。解決。いや、その。
とりあえず、現状では作業中だと閉じないというような判定が入っていためちょっちやややこしい。個人的には
という順序で処理したいわけだ。コレが、
とか言われると腹が立つわけで。最初から「今手が離せないから後にしてくれ」と返したいわけ。
キーを押した時にはまだ、ウインドウを閉じることが通知されていないのでこの時点でいろいろ小細工することは可能。しかし、マウスで閉じようとした場合には小細工するタイミングが無い。もう閉じるつもりで処理を進めるしかない。
なので、現在はウインドウを閉じるように通知されたタイミング(WM_CLOSE)で上に書いたような処理を行っている。キーボードから閉じた時に確認を省略できるのは、WM_CLOSEを発行する時にひねりを加えているため。
マウスでウインドウを閉じる時にはこのひねりを加えるタイミングが無いのでちょっちやこしい。
やるとしたら、確認あり終了と確認無し終了を入れ換える、というところくらいしか思いつかないのだが、これでどうだろうか。
しかし、確認無しで閉じてしまって不都合は無いのだろうか。他のファイラーを使っている時には割とよく有るというか、何かの状態をキャンセルしたくてEscを押したらさっくりとウインドウが閉じてしまって呆然とすることがある。DOSだと、そのままもう一度コマンドをタイプするだけで起動するからいいのだが、Windowsだとそうはいかないというか、またスタートメニューをたどってファイラーを探し出して起動しなくちゃいけない。うっかりキーを間違って終了させてしまった時のペナルティが大きいのだ。
もっとも、なんかキーを押したらシャットダウンしてしまう、と言うのよりはマシだが。
Susieプラグイン、ロードしたらロードしっぱなしになるようにしてしまおうか。どうもメモリリークするやつはリークしてしまうみたいだし。使いもしないプラグインにアドレス空間使われるのは気に入らないけど。
とりあえず手元にあるヤツで調べてみた限りでは
がメモリリークする。
もっとも、たけちんさんもSusieプラグインがこんなにたくさん開発されるというのは想定していなかったようだ。アレだけあると起動時に全部ロードするだけで大変なことになりかねない。
とにかくCtrl+Wのファイル検索、動くようになる。何をどう変えたかというと、今までは検索結果は別途ダイアログに表示していた。
だから、検索した結果のファイルを全部削除したい、というのはちょっち面倒な操作になる。検索して、検索結果のファイルを選択することでそのディレクトリに移動、削除、また検索…、の繰り返し。
これを、
今回、メインウインドウに直接表示できるようにしてみた。直接表示されているので直接操作できる。削除も改名もその場でOkだ。
ただ、罠がある。登録コマンドで使っているマクロ、$Pとか$C。どこからどこまでがディレクトリ部分で、どこからどこまでがファイル名部分かなんて見ちゃいないんだなコレが。特に$cとか$pみたいなDOS8.3形式のエイリアスなんてどうしようという感じ。ファイル名部分については保持しているものの、ディレクトリ部分については保持していないので扱えない。Cのsplitpath()みたいな関数でも作るか。
登録コマンドに"VZ $C"なんて指定していた場合、FDと同じく$Cはカーソル位置のファイル名に展開することになる。上の画面の場合には"VZ BAK\0312\BMP.C"と展開するのがいいのか"VZ BMP.C"と展開したほうがいいのか。
FDはこんなけったいな画面表示をすることが無かったので参考(パクりともいう)にできない。どういう状態が使いやすいのだろう。
秀丸エディタをインストールしていると、エディタの起動に失敗する件を調査。
秀丸エディタは、拡張子.TXTに対して「C:\PROGRAM FILES\HIDEMARU\HIDEMARU.EXE %1」という感じで関連づけている。
WZ Editorだと「"C:\Program Files\WZ Editor\wzeditor.exe" "%1"」になっている。
そう、途中に空白があったのが原因。DFが関連づけられたコマンドラインを解析した結果、秀丸エディタの場合には「C:\PROGRAM」だと思ってしまうのだ。
ちなみに、試した秀丸エディタのバージョンは3.05。もしかしたらものすごく古いヤツなのかもしれない。この件に関しては対応するつもりは無し。
試しに C:\にPROGRAM.EXEという実行ファイルを配置。Explorerからreadme.txtをダブルクリックするとC:\PROGRAM.EXEが実行された。
つまり、DFで行っているファイル名の解析自体に誤りは無いと思う。
リムーバブルメディアのディレクトリを表示中、メディアを抜いて表示の更新をかけたときになんか誤動作するような気がしていたら、メモリ操作を間違っていた。
ポインタに代入せずにそのままfreeしていたので、思いっきりヒープを破壊していたのだ。
CreateDIBitmap()で描画したあと、SetDIBitsToDevice()で再度描画していたのを廃止。
多分、これはSDKのサンプルソースがこういう処理になっていたのだと思う。
友人が来て、DFをダウンロードしたいとか言っていたのであわてて現在のバージョンをアップロードしておく。
アップロードしてから思い出したけど、0.02に向けていろいろいじっていたため設定の仕方が若干違う。あわててヘルプファイルも修正して再度アップロードする。
DFカスタマイザを、キーカスタマイズ以外の部分もカスタマイズできるように昨日追加。
作業継続中。
作業継続中。
SetSystemPowerState()が実装されていない処理系ではハイバネーションとサスペンドを選択不可能にした。
NT、持ってないけど。
$5nとかいう感じで、通し番号の桁数を指定できるようにした。
77,312バイトあったファイルサイズを76,800バイトに戻した。
DFの設定方法について問い合わせのメールをいただく。
ウィンドウズ・パワー９月号へDFの掲載依頼を頂く。許可する予定。
とりあえず誤解は解けたようで何より。
INIファイルの設定で、終了時に問い合わせないようにできるようにした。
画像展開用プラグインは、解放しないようにしていたのを解放する用に変更。
メモリリーク対策としては、オプションでプラグインを解放しないように設定することで回避できる。
今までは、
という動作だった。調べてみると書庫ファイル展開用のプラグインもメモリリークするので、画像展開用のプラグインだけ残していてもあまり意味がなかった。
今後、プラグインがメモリリークしなくなることを願ってどのプラグインも解放できるようにする。
複数のファイルを選択した状態で外部コマンドを実行した場合、$F、$Cなどのファイル名を使用するマクロが含まれていた場合に限り、それぞれのファイルについて連続実行するようにした。
これらのマクロが含まれていない場合には連続実行する価値が無いように思えたので1度だけ実行する。
後はヘルプの記述を更新しないといけないのだが…。これがなかなか。
ついでに画面表示のフォントと色についてもカスタマイザで設定できるといいかもしれない。作るの面倒…。いや簡単なんだけど、簡単なだけに作るのがうっとうしいと言うか。単純作業の繰り返しに近いし。
無くてもいいかなあ、なんて思ってしまうけどＭＳ ゴシックとかって書きにくいことこの上ないし、あったほうがいいに決まっている。
隠しコマンド
ということにして、無かったことに…。
10%から30%程度の高速化。
スタックサイズをリンカのデフォルトに合わせていたけど、512バイトって少なすぎじゃない?
というわけで1MB予約。
DFだけなら1KBもスタックを使わないようにしてあるけど、SusieプラグインとかUNLHA32.DLLのスタック使用量までは解らないしね。
初期設定ではSusieプラグインを解放しないようにした。これでメモリリークしつづけるという状態は起こらなくなるはず。
その代わりプラグインをロックしつづけることになる…。
指定したディレクトリでSusieプラグインを検索しないようになっていたバグの修正。Susieプラグインを解放しないようにしたつもりで、検索しないようになっていた。USEエントリで使用するプラグインを指定していると問題なく使用できていた。
複数のファイルの日付を変更しようとした時、リードオンリーなファイルが含まれているとそれ以後のファイルの属性がダイアログに表示されているものに変更されてしまうバグを修正。
ここまでの修正を加えたものをバージョン0.02として公開。
起動をもう少し速くできないかと思って、各部分でラップタイムをとって調べてみる。実際にドコの処理で時間がかかっているのか確認してから改良しないと苦労しても意味がなかったりするし。
で、調べてみるとウィンドウの生成で一番時間がかかっている。この中で一番時間を費やしているのは…。CreateWindow()。APIやんけー。
というわけであきらめる。
てっきり、こう、INIファイルの読み込みとか、メモリの初期化で時間がかかっているのかと思ったもので…。この辺、改善の余地はあるものの10%から20%程度しか時間がかかっていないので。
IE3とIE4のShellExecute()の際を調べる際、どうやってURLプロトコル(http:)とドライブ名(c:)を区別しているのだろうと思ってファイル名を指定して実行を使って実験。.txt://foo はうまくいかない。レジストリをナニしてこういうプロトコルがあるかのように登録すると動いた。次に c:// なんて入力して何が実行されるか試してみた。ハングアップした。ファイル名を指定して実行のバグかと思ってstart.exeで再試。ハングアップした。ShellExecute()に渡してみた。ShellExecute()から返ってこない。
なんか、やる気無くなったのでDFではIE3環境を切り捨ててもいいですか。
いつの間にかshell32.libを破壊していたらしい。Windows NTでDFを使おうとしたら起動しなくてビビる。どうも手元のshell32.libはSHELL32にリンクしているらしく、Windows 9xならうまいこと動くけどWindows NTだとダメダメ。いつから? と思ったら7月に作ったバイナリ(Vectorに公開しているのとかはコレ)は動いた。LibrettoとFIVAと行ったり来たりした時にやらかしたのかも。
Windows NTでDFを使っているとディレクトリの削除ができないバグを発見、殲滅する。
ディレクトリ移動の処理なんかでちょっち根性が足りなくて認証エラーで挫折してしまう現象を確認。アカウントとパスワードを問い合わせるようにするつもり。あのダイアログって標準でもってないのか?
実行時に色を変えてやりたいのだけど、GDIオブジェクトの排他制御をどうするか悩んでいる。同時に二つのスレッドから参照するのでクリティカルセクション使うと、片方が描画中には描画できなくなってしまう。管理用のオブジェクトを作らないとダメかなあ。
DF、Windows NTで動かしたらAlt+Enterでバージョン情報を表示できないというバグを発見。そういえばこのコマンドはWindows NTで試したことが無かった。Office97で使用するDLLのバージョン情報が取得できなかったので自力でバージョン情報を解析して表示していたのが裏目に出た。APIを使った元の処理に戻すことにする。
DFは、ディレクトリの更新通知を受け取ったらすぐに表示を更新するようにしてあるけど、頻繁に更新する時(大量に削除中だったりするとか)だと操作する暇が無いくらいに更新しつづけるのでタイマーも併用することを考える。
何も考えずに実装したら、ファイルのコピー中とかにも表示を更新してしまって訳がわからなくなるというバグを産み出してしまう。
DF、ひっそりと改良。表示を更新したあとは、1秒くらい表示を更新しないようにしてみる。ついでに操作直後にも画面を更新しないようにした。作業用ディレクトリではみ出るほど中間ファイルが生成されたり削除されているようなところだと表示の更新だけでいっぱいいっぱいになってしまって操作できなくなってしまったので。
そしたら、ファイルを削除してもちょっと間を置かないと表示が更新されない。確かに操作直後なので更新しないのは正しい動作なのだが…。
DFのソートが遅いのは文字列の比較が遅いせいだろうと辺りをつける。今のところWin32APIのlstrcmpi()を試用して文字列比較を行っているが、Inside Windowsの1997年4月号p.73によるとWin32APIより50倍ほどランタイムのほうが速いと言うことなので自作することにする。
ちなみに、こちらでテストした結果は
| 関数 | lstrcmpi() | RTL | 自作 |
| 所要時間 | 370ms | 10ms | 5ms |
10,000回ループさせてみた。
DFに組み込んでみてもFIVAにはそれほど大量のファイルが無いのであまり実感が沸かない。
勤務先にある謎の15000以上ものファイルがあるディレクトリを閲覧させてみる。今まで1秒ちょいかかっていたのが0.2秒くらいに短縮。5倍速。ソートが異様に速いアリアドネとも互角に闘えるかもしれない。ただ、ディレクトリエントリの検索はまだアリアドネにかなわない。
[DFって何?][日記][コマンド一覧][関連リンク][予定表][他のファイラー][逃げ帰る]
メールはこちらCopyrigiht © 2001 びい(@nifty ID:RXA01732)