2.4 8:00 【雪景色とdcmd】 いやはや、すごく積もってる。15〜20cmくらいかな。まだ降ってるし……。 影山報告でdcmdのことが書かれていたのでうちでもさっそくやってみた。サンプルになるコードがあると理解しやすくてうれしい感じ。まずはコードをそのままダウンロードしてきてプロジェクトを作成し、初期設定に入れて再起動。ちゃんと動くのかどうかちょっと不安だったけどやってみたらあっさり。こんな簡単に動いていいんだろうかって感じ(笑)。適当に計算させてみてペースト、、と思ったらできない。「できないことがある」と書いてあったのでそんなもんなのかと思いつつ、何度かやってみたがまるでだめ。いろいろなアプリケーションでテストしてみたけどどうもだめみたいだった。 MacsBugでCurApNameを見てみると、ほとんどの場合バックグラウンドで動いているアプリケーションの名前が表示されているのでそのためかも知れない。未確認だがカレントアプリケーション=フロントアプリケーションでないとうまく動かないってことかも。 で、ちゃんとSetScrapが働いているのかどうかをチェックするためにメモリの内容を少しチェック。「LowMem.h」を見るとScrapSizeとScrapHandleのアドレスはそれぞれ0x0960と0x0964だ。ここを見てみればクリップボードの内容が変更されているかどうかがわかるはず。で、さっそく「DM 0x0960」で覗いてみると、クリップボードのデータサイズは更新されていた。内容は、、ハンドルなので内容を見てそのアドレスを……というのはなんか面倒だな。きっと方法があるはず……と、ちょっと話がそれる(笑)。 まず、0x0960というアドレスを知らなくても「ScrapSize」という名前で参照できる。ハンドルの方は「ScrapHandle」だ(大文字小文字は区別しない)。で、Cなら「**ScrapHandle」とやれば実際のデータを覗いてみることができるが、MacsBugではそうはいかない。Syntax Error。で、どこかを読めば書いてあるんじゃないかと思いつつ、ふと、「Pascalならどうだ?」と「ScrapHandle^」とやってみるとこれが見事に成功。例えばクリップボードのサイズをチェックしたいだけなら「ScrapSize^」だけでok。内容を見たい時は「DM ScrapHandle^^」かな。2バイトのもの(ScrapCountとか)の場合は「ScrapCount^.W」とやれば2バイトとしてあつかってくれる。 話を戻してクリップボードだけど、データ自体は更新されているみたい。はっと思ってシステムフォルダの「クリップボード」の内容を見てみるとdcmdを呼び出す前のまま。ひょっとしたらこれがまずいのかも知れないから最後にUnloadScrapを呼んでやる必要があるのかも(未確認)。またPutScrapはメモリを移動する可能性があるような気がするのでメモリの移動をしてはまずい割込みルーチンなんかが実行されている時に呼び出してしまうとトラブルの原因になるかも知れない。これも未確認ながら。アプリケーションがちょうどクリップボードを処理しようとした時……なんてのもまずそうな気もする(笑)。 逆にクリップボードにある計算式を計算してくれる……とかできたらいいんだけどそう簡単にはいかないのかな。クリップボードの内容は参照できるからあとはそれを評価してもらえればいいだけなんだけど難しいか。calcclipとかいうコマンドで普通に呼び出すとデフォルトで16進数で計算、calcclip 10とかやると10進数とか。「-d」とかそんな感じでもいいけど。どっちにしても自分で式評価ルーチンをかかないといけないならFKEYにでもした方が便利だよな……(笑)。 で、関係ないソースの内容のことをちょっと(ほとんど私信だな……(苦笑))。16進数の文字列への変換だけど、サンプルの「Echo.c」に同様のコードがあるからそれを参考にするといいかも。ぼくが作るんだったら、
こんなコードにするかな(動かしてないけど……)。 それからバージョンとか使用法の部分はDcmd.hにそれぞれdcmdFillVersion、dcmdFillStringっていうマクロが定義されているからそれを使う方が簡単かな。使って書き換えるとしたら
こうかな? あと気がついたのは、ほんとにどうでもいいけどクリップボードは「Clipboard」と書くのが正しいんじゃないかなと思ったくらいかな。 次回の予定は、未定。 |
← to February 3, 1999 ↑ to February index → to February 5, 1999 |