[DFって何?][日記][コマンド一覧][関連リンク][予定表][他のファイラー][逃げ帰る]
DFがTECH Winに載るらしい。
反対側のウィンドウの表示ディレクトリを変更できる機能があると便利なのではないかと思う。ディレクトリの内容を確認する時に、
というのはちょっと面倒というか、一々戻るのがうっとうしい。反対側のウィンドウに表示できれば、戻るという一手が不要になる。
問題は反対側のディレクトリを操作する時の排他制御。いまいちいい手が思いつかない。
2chでも指摘されていた登録ディレクトリに名前を付けられるように改造した。これにより26個までという登録数の制限も無くなる。
登録コマンドに名前を付けるのは…拡張子別のがあるせいでうまくいかないので保留。
二画面モードの時に、反対側のウィンドウに表示しているディレクトリを変更する機能を追加。
別スレッドから制御すると排他制御が厄介なので、こっちからは処理を要求するだけにして、向こう側が処理するようにした。
キーアサインを何にするか悩んだものの、Ctrl+Jにしようと思ったところで既に割り当てていたので困る。でも結局Shift+EnterとCtrl+Jに割り当てた。編集と重なっているけど、もともとディレクトリにカーソルを合わせてShift+Enterを押しても何も処理をしていないので困ることはない。ハズ。
その代わり、今までディレクトリにカーソルを合わせて編集コマンドを出しても何もしていなかったけど、今回からはディレクトリの移動を行うことにする。
処理としては
という感じ。
いや、貼り付けるというワケでもないんだけど。
Ctrl+Kでのファイルの作成時にクリップボードにあるテキストやビットマップをファイルとして書き出せるようにした。
エディタでコピーしてファイルにするとか、PrintScreenでキャプチャしてファイルに保存する時に楽になる。
というわけで新機能に対応したヘルプを用意する。
画面のスナップショットも初期設定のものを使うことにする。
80,384バイト。
16bppのBMPファイルが表示できなかった。SDKのサンプル、ShowDIBをパクったところなんだけど、どうもピクセルフォーマットの12バイト分を読み込んでいなかったらしい。
確認のために16bppなファイルを作ってみたかったものの、手元のツールでは作れなかったので挫折。
匿名熱望さんにより、ViXで16bppなBMPファイルを作ることができると教えていただく。コレで動作確認完了。
いやあ、送られてきましたよ。隅の方にちょこっと載ってました。
余計な物は表示しない、というポリシーのもと作っていたので画面写真がすごく寂しいです。ツールバーとかごてごて付いていた方が画面の見栄えはいいみたい(^^;)。
すぐ下にあるアリアドネとかDWなんかだと、ファイルがたくさんあるディレクトリを表示しているもんだからなんか、ソレっぽく見えてるんだけどなあ。
とりあえず、VectorとFWINAL、FGALTLAにアップロード。
ここにあるのとは特に変えていない。しばらく使ってて問題なかったので。
ヘルプでは「関連付け」なのにダイアログでは「関連づけ」になってるし。
アップロード後に思い出した。まあいいや。
Windows 95/98のようなディレクトリ変更通知が受け取れないようなサーバでファイル操作を行った際、画面表示を更新するようにしていたら、その時にソート順しなくなっていたバグを発見。殲滅する。
これは良くないような気がするのでアップロードしなおそう。
ヘルプファイルに誤記があることをメールでご指摘いただく。
フォント指定のところ、例を追加したのだけど、
[FONT]
FONT=ＭＳ 明朝
になっていた。正しくは「FONT=」ではなくて「FILE=」。
そういえば掲示板でのご指摘ではなくてメールなのは恥ずかしい間違いだからこっそりと教えて上げようという意図だったのかもしれない。
なんかせっかくのご配慮を無にしてしまったかもしれない。
@ガッテンさんからDFを掲載したとのメールをいただく。
4月中ごろにも掲載依頼のお話があったんだけど、その時にはなぜかDFのページが表示されない、ということでダウンロードできなかったとのこと。一応、ページを確認してまだダメですか? というメールを送ったところ返事をいただけなかったのでダメだったのだろうとあきらめていたところ。
紹介文はかなり好意的に書いていただけたみたい。ヘルプの逆引きマニュアルについても触れていただいているのはちょっちうれしい。アレ、結構書くのに手間がかかっている物で。
終了時にウィンドウの位置を記録して、起動時に記録されている位置にウィンドウを表示する機能を追加。
というのは独立しているので復元するが記録しないように設定しておけば毎回同じ場所に表示するように設定可能。
最大化したまま終了すると、画面一杯の通常ウィンドウを作ってしまうので対策。元の大きさでウィンドウの位置を記録するようにした。
数字以外は全部区切り記号と判定していたので座標や幅にマイナスがあると誤動作した。
今まではヘルプファイルのパスを起動時に生成して保持していたけど、メモリがもったいないのでやめた。
ヘルプを呼び出した時にヘルプファイルのパスを生成して呼び出したら破棄する。まあ、若干処理時間はかかるようになるけど基本的にはメモリアクセスだけだし、ヘルプファイルの呼出ではディスクアクセスも発生するのでそっちのオーバーヘッドに飲み込まれるハズ。
ユーザーの操作によるインタラクティブな処理だからこの程度の処理時間増加は誤差の範囲内だろうし。
登録ディレクトリと同じように名称を付けられるようにした。
これにより登録数は26個までという制限も無くなる。
登録コマンドと登録ディレクトリの上位10個めまでにショートカットキーを割り当てられるようにした。
キーを押すだけで即座にコマンドを実行したりディレクトリを移動することが可能になる。
ただし、キーカスタマイザがこの新しいコマンドに対応していないので事実上はまだ使えない。
キーカスタマイザに新しいコマンドを追加した。
ヘルプの修正がまだ。
ウィンドウ表示位置の記憶、復元のON/OFFを追加。
この時、Visual C++がファイルを上書きしてくれやがりまして、作業に手戻りが発生したりする。
キーカスタマイザの挙動がおかしいと掲示板で報告をいただいたので動作を見直してみる。
するとどうだ、既に割り当ててあるキーを再度割り当てると、リストに表示されている別のキーの部分が書き変わるではないか。
コレは一体どうしたことだと思ったら、リストボックスに対してソートするオプションがついていた。どうやら外すのを忘れたらしい。
このため、カスタマイザ内部で保持しているキーテーブルの並びとリストボックスに表示している並びとが食い違ってしまい、たとえば同じキーが複数表示されたりという感じで表示がおかしくなってしまう。
拡張子別登録コマンドが動いてねーでやんの。はっはっは。
拡張子の無いファイルに対して *.TMP とかいう感じでリネームコマンドを発行するとファイル名の最後の一文字が消えてしまう。
12345だと1234.TMPという感じ。
DFの登録コマンドに、反対側のウィンドウで表示しているパスに展開するマクロを追加仕様としてハマる。
8.3形式のDOSファイル名と検索モード状態のアレが絡み合って異様にややこしい。毎回DSファイル名を調べてしまう、という手もあるけどCPUタイムとメモリがもったいないので必要になるまで遅延させたい感じ。
テキストビューアを付けてみる。以前実装した時には5KBくらいサイズが大きくなった上にバグが取れなくて結局外してしまったけど、今日作りなおしたら1KBくらいで済んだ。
まだTabコードの処理とか何もしてないけど。そのせいかバイナリファイルを表示させるとGDIが例外出して死ぬかもしれない。
文字コードの変換というか、7bitJISとかも表示できるようにしたいけど、そうなると読み込みバッファの他にもう一つ変換結果を保持するバッファが必要になりそう。バッファを二つ持つのはもったいない気がしてイヤ。読み込んだら逐次変換していくようにすれば変換結果を保持するバッファは要らなくなるけど、文字コードの切りかえ時にもう一度読み直さないとダメか。ソレもイヤだ。
DFのテキストビューア、ウィンドウ幅に合わせて折り返して表示するようにする。
スクロールさせるのが面倒。
上に戻る処理ってなんか定石みたいのは無いのだろうか。行頭から探していくしか思いつかない。PageUpとかだと面倒で仕方がない。
何が面倒って、CRLFからCRLFまでの論理的一行の文字列が、ウィンドウに表示した時には何行分になるのかというのが解らないから。
DFのテキストビューア。一応、スクロール機能を付ける。効率がいい方法が思いつかなかったのでとりあえず無理やりコーディングして動くようにしておく。上に戻るのが遅い〜。
いや、遅いのは描画というか、文字列の幅を計算する部分なんで、そこを省略してしまえばいいんだけど。プロボーショナルフォントを使った時のことを考えると、描画してみないと文字の幅が判らないモノで。UNICODEに変換しておいて全部の文字の大きさのテーブル作れば速くなるかも。
画像ビューアとかが動かないという件、動作ログをとって送っていただいた。
DFのビューアってまず
という動作をしているのだけど、ログを見るとWavファイルの再生に成功している。
何が成功やねん。
音源ドライバがタコっている?
高速化といってもアルゴリズム的にどうこうというのではなくて、速いように見せかけるという。
CPUパワーを駆使して高速化するよりも、見た目に遅いと気づかれなければOk。CPUパワーを占有すると他のプロセスが遅くなるし。CPUパワー保存の法則が働いているので、なにかプログラムがCPUパワーを使うと、別のプログラムの取り分が減ってしまう。
具体的にはどうやるかというと、何らかの処理を行うためにCPUパワーが必要で、その処理に時間がかかる訳だから
処理しなければよい。
あとは、処理を遅らせる。
処理速度を遅くするのではなくて、処理を始めるタイミングをできるだけ遅らせるわけ。すぐに必要ではない処理というのはどんどん後回しにしてしまう。で、暇な時にでもその処理を行う。
テキストビューアからエディタを起動できるようにとかいろいろ機能を追加。
Shift+Enterなど、エディタ起動コマンドなどが使用可能に。キーカスタマイズしている場合にはそちらが使われる。
DF本体のウィンドウと同じように移動、サイズ変更も可能。
DFのテキストビューア、スクロールが遅いのは仮想画面からのBitBltに時間がかかるせいなので、仮想画面を作らずに直接描画して見る。
余計遅くなる。んがー。
画面から画面へのBitBltの方が速いので、上に何も重なっていなければいいのだけど。上に何かウィンドウが重なっているのか、ドコに重なっているのか、というのを取得してやればいいのかもしれない。
ダイアログで仮名漢字変換をONにすると、そのまま使用中になっているらしいので、ダイアログを閉じる時に仮名漢字変換をOFFにするようにコーディング。
メインウィンドウでは仮名漢字変換は使用不可にしてあるのでOFFになるもんだと思っていたらONのままで、なおかつ使用不可なもんだから操作もできないという。
まあ、なんかダイアログ開けば操作可能なのでどうでもいいといえばどうでもいいのかもしれない。
テキストビューアのフォントと表示色を設定可能にする。
[COLOR]セクションのTEXTとTEXTBAK。
フォントを起動時に生成してそのまま保持していたのを止めて、描画時に生成してすぐに破棄するようにした。
今までフォントのハンドル4バイトを保持していたのに対しフォント名を保持するようになったので若干消費メモリが増えているハズ。その代わり限りあるGDIリソースを消費しないようになるのでこちらのほうがいいかも。
Windows NTならリソースの制限が無くなる…とか思っていたら、単に限界値が大きくなっただけでリソースの制限値はあるらしい。
実行ファイルが大きくなったので、黒魔術を掛けてみるものの効果無し。
引数にパスを指定すると、そこをカレントディレクトリとして起動するようにした。
アクセス制限があるところには移動できないので、その場合には後で再度移動していただくことに。
11月28日にフォントを保持しつづけないようにした悪影響で、ファイルを選択してコマンド実行した時に出で来る一覧ウィンドウのフォントがシステムフォントになっていた。
無効なフォントハンドルを指定していたハズなのでエラーになっていたかもしれない。
NetWare3.21Jサーバに対してファイルをコピーすることができない、と報告していただく。
NetWareはOS/2モジュールを突っ込まないと長いファイル名が使えないので、このあたりでコケているのかもしれない。
ディレクトリのコピーを行うルーチンで判定ミスをする恐れがあるところは見つけたので修正。
ディレクトリのコピーではなくてファイルのコピーでコケているらしいのでここではないとは思う。
Sound Blaster Live! を使っているとビューアが誤動作する、という話なのでビューアコマンドを増設する。
既存のビューアはWaveファイルの再生を試み、失敗すると画像ファイルとして表示を試み、それも失敗するとテキストと判断して表示しているんだけどどうやらどんなファイルでもWaveファイルとして再生できてしまうという。
仕方がないので
の二つを追加。
標準ではキーを割り当てていないので、ビューアがうまく動作しない人はこちらを割り当てて使っていただきたい。
勤務先でDFを使っていると、HP_Network_Printers というプリンタサーバを検索中に無限ループすることがある、というか大抵無限ループするという現象を見つける。何かと思ったらネットワークドライバが不思議な挙動をしている。
こいつが居ないネットワーク上では意図した通りに動作する。
誤動作する時のログを送っていただき原因解明。
LFNに対応しているかどうか判定するためにGetVolumeInfo()を呼び出しているが、これが失敗しているためにリトライするかキャンセルするか問い合わせている。
無視して続行、という動作は考えていなかったのだ。
失敗した時にはLFN対応済みとして処理することにする。
展開時にUNZIP32.DLLを使用するように修正。
UNLHA32.DLLでの展開に失敗したらUNZIP32.DLLを使うようにしてある。
一つ一つのファイルでUNLHA32→UNZIP32というように切り替えていってもよかったのだけど、おそらくZIP書庫を展開した場合、次に展開するのもZIP書庫である可能性が高いので次のファイルはUNZIP32.DLLで展開を試みて、失敗したらまたUNLHA32.DLLを使うようにした。
もっとも複数のファイルを選択してまとめて展開する、ということ自体が少ないような気もする。
[DFって何?][日記][コマンド一覧][関連リンク][予定表][他のファイラー][逃げ帰る]
メールはこちらCopyrigiht © 2001 びい(@nifty ID:RXA01732)