昔の最近の出来事(2011.06)

2011/06/30

遅めに帰着。

ベースの仕込みは完了。細かい飾りをどうしようか。

2011/06/29

遅めに帰着。

なんかキーボードの調子が良くなくて、突然変なキーを押しっぱなしな感じになったり。 なんとなくCntlキーがへたってるのが原因の予感。

2011/06/28

日付越え前に帰着。

飾りの部分が面倒臭いなぁと思ったりも。

2011/06/27

日付越え前に帰着。

なんとなく固まってきたかも。むしろ体裁を整えて詰めるのが面倒臭い。

2011/06/26

昼過ぎ起床。

もそもそとコーディング。むー、意外と面倒臭い。

2011/06/25

昼頃起床。

調べ事したりもそもそとコーディングしたり。

2011/06/24

日付越え。

あまりの眠さに急速停止。

2011/06/23

日付越え。

ちょろり調べ事をして終了。

2011/06/22

遅めに帰着。

もそもそとコーディング。

2011/06/21

遅めに帰着。

ちょろりコーディング。

2011/06/20

早めに帰着。

思い付きで全く関係の無いコーディングを始めてみたり。

2011/06/19

起きたら午後もいい時間。

もそもそとコーディング。ダイアログボックスクラスを改善してみたり。 フォーカスがメインウインドに戻らない件について。そもそもこれが諸悪の根源 だったのですが、その原因は モーダルダイアログっぽい動きをさせる為に、 EnableWindow(hwnd,FALSE)(つまりDisable)を使って親ウインドのメッセージ受信 を停止してるからでした。
これを実行してしまうと、元のウインドから他のウインドにフォーカスが移って しまうのですが、再度フォーカスを取り戻す事ができないという事のようです。 で、EnableWindow()は使わずに、メッセージループでメッセージをディスパッチしない という方向で処理してみたり。ついでに、ダイアログボックスが開いている間に メインウインドに(タスクバーなどから)最小化メッセージなどが送られた場合でも そのメッセージだけはディスパッチするようにしたりして、なんとなく前よりマシ になった気も。

あと、comctl ver6でダメになっていたのでもう一つ。ステータスバーに メッセージが表示されなくなってました。原因はSendMessage()の SB_SETTEXTを使って表示したいテキストを指示する訳ですが、その時の WPARAM 値に255を指定してる為でした。 即値で255を指定していたのですが、本当はSB_SIMPLEIDなるdefineらしい。 でも、DのWinAPIラッパには無いのでそもそも使えるものなのか否かが判りません。 で、0を指定すれば ver6でもOKとなりました。WebでSB_SETTEXTを検索してみると WPARAMに255を指定している例がかなり多く存在していますが、 こういうのもハマる原因なのかも。

最後に作りの問題でもう一つ。ダイアログクラスでボタンのスタイルにWS_TABSTOPを指定 したとき、何故か二つ目のボタンにフォーカスが向いているのにアクティブに ならないという現象に遭遇しました。原因から言うと全てのボタンのスタイルに 「BS_DEFPUSHBUTTON」を指示している為でした。観察結果から動きを想像すると 次のような感じ。
このボタンスタイルが指示されると縁が黒いボタンが生成されます。 WS_TABSTOPによるフォーカス移動に連動している。この時、 他のボタンにフォーカスが移るもしくはフォーカスが移動してくると、 黒縁の状態が「反転」されます。

┏━━━━┓┏━━━━┓
┃btn1(f) ┃┃btn2    ┃ 最初はbtn1にフォーカスしてる。両方とも縁黒ボタンに設定されている。
┗━━━━┛┗━━━━┛
           ↓                            ↓
┌────┐┌────┐ TABを押す。btn1はフォーカスを失うので状態反転して縁黒は解除。
│btn1    ││btn2(f) │ btn2はフォーカスを得るのですが、こちらも状態を反転 するので
└────┘└────┘ 縁黒が解除される。この為Enterキーを押してもbtn2は効かない。

これを、最初にフォーカスの合っているボタンにだけBS_DEFPUSHBUTTONスタイル を指示すると、

┏━━━━┓┌────┐
┃btn1(f) ┃│btn2    │ 最初はbtn1にフォーカスしてる。btn1だけ縁黒ボタンに設定する。
┗━━━━┛└────┘
           ↓                            ↓
┌────┐┏━━━━┓ TABを押す。btn1はフォーカスを失うので状態反転して縁黒は解除。
│btn1    │┃btn2(f) ┃ btn2はフォーカスを得て、こちらも状態反転して今度は縁黒に
└────┘┗━━━━┛ 設定される。

そんな感じ。

2011/06/18

昼前起床。

たぼさんちの 2011/6/16の雑記。ども、助言いただきありがとうございますm(_'_)m

ちらつきの話。TANEの書き方がマズくてTrackbarのちらつきのように読めますね(^^; WindowsXPビジュアルスタイルになってないのに気づいたきっかけが、 最初にTrackbarの存在を知った時という事で、ちらつきの話はTrackbarに だけではなく全般的なコモンコントロールに関連した話題でした。
さておき、ちらつきの再現について。 D言語でウインドクラスを実装したときの話 のwinapp_110606.zip内のwinapp.exeと同じディレクトリに このmanifestファイル(winapp.exe.manifest) を置いていただき、実行後ウインドサイズを変更すると、 言わんとしてる事が判るくらいちらつくと思います。 ただし、WindowsXPで「画面のプロパティ⇒デザイン」の項目を 「ウインドウとボタンをWindow XP スタイル」に、効果内の 「ドラッグ中にウインドの内容を表示する をON」にする必要があります。 ウインドウとボタンの項目が「Windowsクラシックスタイル」だと manifestファイルが無いのとちらつき具合は変わらないようです。

根本的な作りの問題であれば、スタイルによらず ちらつくと考えられる 訳ですが、comctl32.dllの ver5だと大丈夫だったのがver6だと大丈夫 じゃなくなった点が納得いかないと言いますか。 ちなみに、Rebarは手持ちコードの中でもこのテストアプリでしか 使ってなかったりします(^^; なのでさほど重要でも無いのですが、 なんとなく負けた気がするので調べているという感じでしょうか(^^;;;

因みに、作っていただいたTrackbarのテストプログラムを試させていただき ましたが、これくらいだとおっしゃる通り気になるレベルではないですね。

あと、BringWindowToTop()を使っている理由について。ダイアログを 閉じたあと、何故かフォーカスが元のウインドに戻らず、100%他のウインドに 移ってしまうという現象が起こりました。この時、他のウインドにフォーカス が移った上に、そのウインドが最前面に出てくるという動きになっていた (たぼさんの言う「普通は...」の動作に何故かなっていない)ので、 どうしたもんかと困ったあげくBringWindowToTop()を使うに至ったという訳 です。SetFocus()くらいで大丈夫だろうと思っていたのですが、何故か時々 Zオーダーが一つ下がる?(フォーカスは元のウインドに移るものの、他のウインドが 最前面に出てくるというのがどうにもならない感じ)場合があった為、しかた無く BringWindowToTop()を選択したというのもあります。 何か作りが悪いのかも知れません。決してポリシーがあって使っている訳では 無いです(笑

そういえば、最近 デスクトップPCの電源が入りにくくなっています。 前面のボタンを一回押しただけでは反応しなくて、もう一度押して電源が 入るという感じ。ところがここ数日、二回でも入らない場合があったり。 今のはまだ5年経ってないのでもう少し耐えて欲しい所なのですが。

2011/06/17

日付越え。

あまりの眠さに急速停止。

2011/06/16

日付越え前に帰着。

ちょろっと調べ事をして終了。

2011/06/15

遅めに帰着。

もそもそとちらつき調査。「WS_EX_COMPOSITED」というウインドスタイルの存在を知ったり。 WindowsXPで使えるウインド描画時にダブルバッファでちらつきを改善するスタイル らしいのですが、正しく描画されない上にモッサリ動作になったりで特に何も解決せず。

2011/06/14

遅めに帰着。

先日のちらつきの続き。どうもrebarをMoveWindow()でサイズを変えた時、 再描画フラグをtrueにすると、全ウインドに再描画メッセージが送られているっぽい。 しかし、MoveWindow()の再描画フラグをfalseにするとボタンの隙間とかにゴミが残ります。 そこで、InvalidateRect()を使ってrebarの領域だけを再描画させるようにしたところ、 ちらつきが軽減されました。
自分描画のウインドは WNDCLASSEX のメンバー変数 hbrBackgroundにnullを指定するなどして、ちらつきが 起こらないようにしているのが効いているのですが、コモンコントロール(例えば ListViewとかTreeViewとかEditコントロールとか)だけが異常にちらつきます。 これが「解消」ではなく 先に述べた「軽減」にかかっている理由です。
Vistaのコモンコントロールだと、ListViewだけは特別に「TVS_EX_DOUBLEBUFFER」なる スタイルが追加されているようなのですがXPでは使えなさげ。

2011/06/13

遅めに帰着。

そういや以前、WindowsAPIの コモンコントロールであるTRACKBARといういわゆるスライダーの存在を知りました。 このとき、ツマミの感じが違う何やら古臭い感じのが出てきた訳ですが、 新しい感じのにする方法が判らなくてそのまま忘れていました。なんとなくWebを 検索していると、新しい感じにする方法を知ったり。 「Windows XPビジュアルスタイルの使用」 という少し古い文書ですがこういう事らしい。 古いのを「comctl32.dll version 5」、新しいのを「comctl32.dll version 6」 と言うらしい。

で、ちょっと試しに変えてみたのですが、 確かに新しい感じにはなるものの、何故かウインドのサイズを変更すると激しく ちらつく感じだったり。 Rebarコントロールを使うとちらつくというのは以前 遭遇した問題だったのですが、このときはRebarコントロールのstyleにWS_CAPTIONを 追加すると何故かちらつかなくなるという謎の方法で回避してました。 ver6にするとこの裏技が効かないという事のような予感。

もう少し調べてみると、WM_ERASEBKGNDをハンドリングするという方法があるらしい。 でも、イマイチ効果のほどが判らず。そもそも WNDCLASSEX のメンバー変数 hbrBackground に null を指定するのとは意味が違うのかしら?

2011/06/12

昼過ぎ起床。

たぼさんちの 2011/6/8の雑記。どうも見てくだすってありがとうございますm(_'_)m インスタンスの削除について。一応削除については考えていたつもりなのですが、 言われてみるとなんだか少々怪しい感じだったので見直してみました(^^; WM_NCDESTROYの存在を把握していなかったのですが(^^;これを使えば、 ハンドルの生存期間とインスタンスを登録したハッシュのキーの生存期間が 少し離れている感じだったのとか、CreateWindow()が失敗したときに ハッシュキーが削除されていないなどの不具合が解決できたかも。

GT5のアップデートが来ていたので一応アップデートしてみたり。配信イベントが いくつか増えていたのをちょっとやったり。

2011/06/11

昼頃起床。

昨日のビルドはどちらもエラー無くmakeできていたり。ん?Linuxの方はともかく、 MinGWの方も?......これは怪しい(笑

で、Linuxの方をmake installして手持ちのテストコードをコンパイルしてみた ところコンパイラがcoreダンプ(^^; 少し調べてみたところ以下のような感じ。

[tane@fedoravmw test]$ ulimit -c unlimited
[tane@fedoravmw test]$ gdc -v
組み込み spec を使用しています。
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc_2053/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
ターゲット: i686-pc-linux-gnu
configure 設定: ../configure --prefix=/usr/local/gdc_2053 --with-gmp=/usr/ --with-mpfr=/usr/ --with-mpc=/usr/ --enable-languages=c,d --disable-shared --disable-bootstrap
スレッドモデル: posix
gcc バージョン 4.6.0 20110325 (gdc hg, using dmd 2.053) (GCC)
[tane@fedoravmw test]$ gdc mem_test2.d
Segmentation fault (コアダンプ)
[tane@fedoravmw test]$ ls core*
core.26900
[tane@fedoravmw test]$ gdb -q -c ./core.26900 gdc
Reading symbols from /usr/local/gdc_2053/bin/gdc...done.
[New Thread 26900]
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/25/7d0d6467b9f4374470e0384a3e602be99b058e
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `gdc mem_test2.d'.
Program terminated with signal 11, Segmentation fault.
#0  process_command (decoded_options_count=5, decoded_options=0x8b5fb08)
    at ../../gcc/gcc.c:3938
3938          switches[n_switches].part1 = "pthread";
Missing separate debuginfos, use: debuginfo-install glibc-2.13-1.i686
(gdb)

coreダンプサイズがデフォルトで0になっていたのを変更する必要があるのですが、 csh/tcsh系で言うところのlimitシェルコマンドが sh/bash系ではulimit って名前 だってのを初めて知ったのは秘密。gcc-4.6.0単品でのビルドもうまくいくのか 良くわからなかったりするので、もう少し待った方が良いかも。

で、MinGWの方。手持ちコードをいくつかコンパイルしてみました。今回の変更では コードの書き換えが必要な箇所は無し。1つだけダメなのがありましたが、 他はなんとなく大丈夫っぽい気が?

一通り手持ちコードを確認終了。gdc2.052でダメだったけど、2.053も引き続きダメなのは 以下。


gdc2.053対応で直ってそうな気がするのは以下。


こんな感じみたいです。そんな訳なのでgdc2.053に乗り換えてみようと思います。

ところで、今回はbitbucket の方を見てても、あまりバグ報告っぽいものが挙がってません。誰も試していないのか 問題が無いのか、区別が付かないのが難しい所です(^^;

ワンセグで録画してあったサイエンスZEROを観たり。動物の模様が細胞の遺伝子レベル でプログラムされているものではなく、数式で表現可能な規則に従って描かれている ものだとか、その数式が 「アラン・チューリング」によって予言されていたとか、興味深い話が 沢山ありました。でも、そちらよりも、模様の観察の為に飼われた「タテジマキンチャクダイ」 の模様が、何故縦縞?横縞じゃないの?って事の方が気になってしかたありません でした(^^; 因みに、Webで検索してみると 魚は頭から尾びれにかけての縞を縦縞と定義しているようです (参考)。

2011/06/10

遅めに帰着。

2.053対応されたgdc(r567)のビルドを試してみたり。いくつかバリエーションを 試す事に。というのも、MinGW+gcc4.6.0+gdc2.053(r567) だと make途中でずっこけた為。 コンパイルエラーだったのであんまりよく見てません。で、 MinGW+gcc4.5.2+gdc2.053(r567)と、Linux+gcc4.6.0+gdc2.053(r567) の二本立てでビルド をしかけた所で眠くて死亡。

2011/06/09

遅めに帰着。

ちょろっとWebを巡回して終了。gdcの2.053対応キター。gcc-4.6.0対応をやっていた ようなので、もう少し来るのは後かなと思ってましたが。週末にでもビルドしてみよう。

2011/06/08

遅めに帰着。

少し古い話題になりますが、IBMの開発した質問応答システムの ワトソン。 クイズ番組で優勝するという快挙をなしたシステムです。 「2001年宇宙の旅」に登場するHAL9000 の HALは IBM(H←I, A←B, L←M)から付けられたと いうのはただの俗説らしいのですが (Wikipedia)、 実際にHALっぽいものを作るのはIBMだったりするのかも? そのうち、Web検索で色々引っかかり過ぎてよう判らんみたいな事も無くなり、 ズバリ答えてくれるようになるのかな? 宿題やらせたり代わりにテストを受けてくれたり.......便利になり過ぎて 人間が退化しそう(笑

2011/06/07

遅めに帰着。

ちょろり調べごと。

2011/06/06

遅めに帰着。

ちょろり調べごと。

2011/06/05

起きたら午後もいい時間。

ちょろり本屋に。「バクマン(13)」。相変わらず平丸の出てくる話は面白いなぁ。

プロ遊の下のプログラミングリソースに 「D言語でウインドクラスを実装したときの話」を 置いてみたり。単なる覚書きですが御参考まで。

2011/06/04

起きたら午後もいい時間。

大家さんに家賃を払ったとき「ここ、3年後くらいに取り壊すから」と言われたり(^^; 確かに築年数も相当経っているのもあり、まぁしかたないかなぁとも思ったり。 更新時期にでも新しい引越し先を考えようかなという感じで。まだ1年半ほど先ですが(^^;

もそもそとコーディング。そういや覚書き。FTP転送でSocketStreamから読み出すバッファ のサイズを64KBにしてました。ところがこのサイズだとFTPサーバによっては途中で レスポンスコード426(何らかの原因により、コネクションをクローズし、データ転送を中止) が返ってきてうまく転送できない場合がありました。原因が判らなかったので困ったの ですが、バッファサイズを256KBにしてみたところ426で切られる事は無くなりました。 それにしても、普段は何も気にする事無く使用しているftpなのですが、自力で プログラムすると、思った以上に面倒臭かったです。

2011/06/03

日付越え前に帰着。

ちょろりコーディング。眠くて死亡。

2011/06/02

遅めに帰着。

ちょろりコーディング。

2011/06/01

早くも無く遅くも無く。

もそもそとコーディング。


TOP PREV