AB開発日記

ここ数日、最適な室温のおかげなのか要因は不明なのですが、開発作業時の集中力がいつもよりも高いような気がします。

そこで、なかなか手を出せなかった機能の一つ。デバッガのアタッチ機能に取り組んでみます。

デバッグを行う上で、プロシージャ階層やスレッド情報を実行側が管理しておく必要があるのですが（だからデバッグコンパイルとリリースコンパイルがあるのです）、アタッチ前の状態ではデバッガとの意思疎通が取れない状態になっています。

そんなこともあって、VC++などはどうやってアタッチ前の情報を仕入れているのかなと。。。不思議に思ってはいたのですが…。

どうやらアタッチを行った瞬間に、それまでのデバッガに流れるべき実行状態が垂れ流しで送られてくるようです。タネも仕掛けもありませんでした（ある意味ホッ

通常、デバッガは下記の2つのいずれかの方法でターゲットアプリのデバッグを開始します。

• CreateProcessで起動（DEBUG_PROCESS または DEBUG_ONLY_THIS_PROCESS を使用）
• DebugActiveProcess

後者の方法をとればアタッチを行えるので、そのようなコードを書いていきます。何気に、DebugActiveProcessでアタッチを行った直後に流れてくるDLLのロードイベントでは、通常の方法ではDLL名を取得できないようなので、モジュールアドレスからGetModuleFileNameExで取得することにします。

こんな感じで、実験段階ではアタッチが成功しているので、実用段階までインターフェイスを煮詰めていきたいと思います。

これで、ABでのデバッギングも少しはラクになるかな〜なるといいな〜

ヒマな時間を活用して、がっつり作りこみました。

Win32/Win64アプリ共にアタッチを行えます。デバッガの32/64切り替えはIDEが自動的にやってくれるので、ユーザーは意識しなくてよい仕様に仕上がりそうです。

今のところ、問題はなくテスト稼動が遂行しております。このまま、何も無ければ今夜はゆっくりとテレビでも見てくつろげます。

普段使い慣れているものに限って、メンテナンスを忘れてしまうということ、ありますよね。

特にマウスなんかは良い例です。今や光学式がほとんどでコロコロマウスがほとんどなくなってきたので、ボールをはずして掃除するということは無くなりつつあります。

しかし、日常的に使うものであれば、”汚れ” は必ず付きます。通常はホコリが圧縮されたものが裏側に着く程度だと思うのですが、私のようなハードユース者は表面のゴム素材が剥れ、元のデザインが分からなくなってしまうくらいに変わり果ててしまうこともあります。

他人であればすぐ気づくのも、いつも使っているもの、ちょっとずつ汚れていくものは自分では気づきにくいです。

今朝、なんとなくなのですが、マウスの細かいところまでじっくり観察して、相当汚れていることが判明しました。

潜在を含ませたタオルで磨きまくったのですが、もはや手遅れ。その劣化を隠すことはできません。ただ単にカッコ悪くなるだけなら良いのですが、磨けば磨くほど、ゴム素材がヘタッてベトベトしてくるんです。

長年使っているものだけに（かれこれ5年…）、反応速度、ボタン配置、フィット感、クリックの感触など、体が覚えている状態なんです。ノーパソのマウスに切り替えてみたものの、なんかしっくりきません。

ということで、本日は私の商売道具でもある大事な大事なマウスを買いに、久々にPCショップに行ってきます！おっと、その帰りに本屋でも寄ってネタでも探してくるか…

ODBCのデータソースドライバをインストールする関係で、コンパネからODBCアドミニストレータを開いているところなのですが、私の持っている64ビットWindowsではドライバが揃っていないみたいなのです。

コンパネから起動するODBCアドミニストレータは純粋な64ビットアプリなわけで、当然ながら64ビットドライバを探しにかかることになります。

ODBCドライバが揃っていないんだから、親切に32ビット版のODBCアドミニストレータをコンパネに置いておいてくれれば問題ないのですが…。そういうところの配慮のなさが64ビットWindowsを買ったのに、32ビット版に再インストールしてしまうユーザーを増やしていることと思います。

そこで32ビット版のODBCアドミニストレータはどこにあるのかということになりますが、下記のフォルダにodbcad32.exeというファイル名で格納されています。

• C:\Windows\SysWOW64\

これはWOW64として実行可能な32ビットアプリ（またはDLL）が格納されているフォルダなのですが、なぜかフォルダ名の末端には “64” という表記があります。まぁ、WOW64というのが正式な略語だということはわかるのですが、純粋な64ビットアプリがそのフォルダのちょい上にあるSystem32にあることを考えると、いかがなものかと。

ようは、

• 64ビット … C:\Windows\System32
• 32ビット … C:\Windows\SysWOW64

ということなのですが、、、逆じゃないかと。。。大体この点から紛らわしいんですよ。”Program File” フォルダだって “Program File(x86)” という表記になっているんですから、”system32″ と “system64” に分けるだけでいいんじゃ…。

まぁ、何かしら理由はあると思うのですがね。こういうところで時間を食ってしまうことがたたあるので、Windows Vistaではスムーズにことが運ぶことを祈ります。

ABユーザーのToshiさんが開発されるタブ型ブラウザToss、各種コントロールがどのような構成で実現されているのかに興味を抱きつつ、ダウンロードしてみました。

まずはIEコントロールの埋め込みに関して。ウィンドウにIEコントロールを埋め込むだけであれば私もやったことがあるのですが、細かい部分でのイベントのやり取りがABのみではあまりうまくいかなかったのを覚えています。結局、COMとATLをAB上でどのようにカバーするのかがポイントになります。

何気に気に入ったのは、レバーコントロール、ツールバーコントロール、タブコントロールがスッキリとキレイにまとまっていたこと。アルファ版ということで機能こそ多くはないものの、好感が持てるインターフェイスは今後とも継続してもらえるとうれしいかも。。。デザインセンスで突き進むのであれば、メニューをオーナー描画してLunascpaeみたいにするのもアリかもしれません。

実用に耐えうるバージョンまでもっていくにはいくつかの壁を乗り越える必要がありますが、そのような方向に少しでも近づいていくことを祈っております。

Toss開発元ページ:

http://toshi.my.land.to/

ちょっと探しているのですが、なかなか見当たりません（ないのかな…）。

日本語、英語の双方向の翻訳ができれば良いのですが、、ちなみに、WebサイトからのAPI呼び出しではなく、アプリケーションが要求を出して、結果をテキストベースで受け取るという用途を考えているのです。

Google Translate（米）であればスクレイピングすることができそうなのですが、「アプリケーションからの用途でも使って良いよ」という記載（っつか、サイトからも）が見当たらなかったので現状だとダメっぽいです。。。

うーん、さすがにCPUを食い尽くす処理をしていそうな翻訳サービス、WebAPIにできるほど余裕が無いのか・・・いや、今どきそんなはずは、、、うーん、わからん

開発に協力いただける方々に向けたsourceforge上のソースコードの整備が一段落しました。なんでこんなに面倒なんだろうか。。。

私一人が面倒な目にあうのは良いのですが、協力いただく皆さんにも、同じように環境を整えてもらわないとリポジトリにアクセスすることができません。関係者の皆さん、お手数をおかけしますが、よろしく頼みますm(__)m

開発者グループに向けた解説文も書いてはみたものの、他の環境で何の問題もなくことが運ぶのか、ちょっと心配です。間違いなどがあったら訂正に走りますので、暖かい目で解説文をお読みになってください。他のWebサイトの情報を参考にされるのも当然アリです（といって逃げてみるf(^^;;;）！

ふぅ〜、何の変哲もない月曜日の夜ですが、一杯やってます(*^_^*