What's new

MFCの難しいところ(その2)

2016年8月29日

2つ目は、MFCでちょっと変わったことをしようとしたとき。
性格には、たぶんMFCコーディングが完璧にわかってさえいれば問題にならないことなのだろうけど、中途半端に知識があるばっかりに問題を難しくしてしまうことだ。

今回苦労したことのひとつに、メニューの状態を変化させるということがある。
みくみくオセロでいうならば、ゲーム中とそうでないときでメニューの状態を切り替えている。
例えば、ゲーム中は打ち返してくるコンピュータの強さを変更できないようにしている。
これは単純にゲームの最中にコロコロ強さを変えられては困るから、あえてゲーム中は選択できないようにしている。

これを実現するには、ゲームがスタートした段階でメニューを無効化し、ゲーム終了と共にメニューを有効化すればよいことになる。
理屈は簡単でしょ。

しかしウィンドウズプログラミングはそんなに甘くない。
ゲームがスタートした段階でメニューを無効化する命令を送っても、実際にはメニューは無効化されない。

これはコーディング方法が悪いとかそういうことではなく、ウィンドウズの構造がそもそもわかっていないことに問題がある。

どういうことかというと、そもそもメニューというのはあらかじめ準備されているものではなく、その場の状況により内容が変化するものであるということを理解せねばならない。
ということは、メニューが表示される瞬間に、現在あるべきメニューの状態を組み立てねばならないということになる。

このあたりの理屈がわかってくると、自動的にもうひとつの問題にぶつかる。
それは、どうやってメニューが開かれる瞬間を知るのかということ。

実はこれはメニューが開かれようとしているということをウィンドウズが通知してくれるので、それを受け取る部分を作ることで解決できる。

ならば、前回にも書いたオセロ盤を描いている「CView」から派生した「C…View」にその部分を作ればよいことになる。
かんたんじゃん!
とおもうでしょ。

ところがこれだと思ったとおりにならずメニューは変化しないのだ。
やはりウィンドウズプログラミングはそんなに甘くない。

ではうまくいかない原因はなんだろうか?
大まかな理屈は間違っていないのだから、そのプロセスに問題があることになる。

前述したウィンドウズがメニューを表示する直前に、メニューを作っているという理屈は間違っていない。
問題はメニューが表示される瞬間、ウィンドウズから通知されるメッセージを受け取る部分を作る場所に問題があるのだ。

ぼくはオセロゲームという性質上、画面繊維のことを考えてほとんどすべての処理を「C…View」クラスのファイルに書き込んでいる。
これはMFCの性質上、仕方ないことだと思っている。

なぜなら前回も書いたようにMFCでは役割ごとにプログラムファイルが分割されている。
そしてご丁寧にもその各ファイルはお互いに独立しており、お互い簡単には干渉できないようになっている。

したがって、別ファイルにウィンドウズから通知されるメッセージを処理する部分を作ってしまったら…。
相互に連絡できなくなり、思ったようにメニューを変化させられなくなると思ったのだ。

しかし、オセロ盤を描いている「C…View」に作ってもうまく動作しないのだからしかたない。
ここはマニュアルどおり、ウィンドウのフレームを管理しているファイル「MainFrm」にメニューを変化させるプログラムを書き込むことにした。

そうなると、どうやってウィンドウのフレームを管理している「MainFrm」と、オセロ盤を管理している「C…View」で連絡を取り合うのかということが問題になる。

残念ながら10年以上もMFCと距離をおいていたぼくにはその解決法が思いつかなかったので、ネットで検索しまくった。
ぼくが悩んでいることはきっとどこかの誰かも悩んでいるに違いない。
そう信じて検索を始めて3日後、やっと見つけた。

その方法とは、ウィンドウのフレームを作っている「MainFrm」をポインタにして、オセロ盤を管理している「C…View」から呼び出すというもの。
べつにどっちが呼び出す側になろうとも、ようするに状態が変化したことを通知できればそれでよいのだ。

これでやっとメニューの状態を変えることに成功した。

たぶんきっともっとスマートにやる方法があるはずだけど、今のぼくにはこれが精いっぱい。

MFCの難しいところ(その1)

2016年8月28日

東京から帰ってきてやっと少し落ち着いてきたので、久々にブログ更新。

今回はみくみくオセロを作っているときに気づいたことを書いておく。
性格には目の見えない人間がMFCプログラミングに挑戦したとき、必ずといってもいいほどぶちあたる壁について書いておく。

一言でMFCの難しいところといっても、大きく分けると3種類あると思う。

1つ目は、MFC固有の考え方になれること。
コーディング手法であったり、変数の型だったり、クラスの親子関係とか…。
MFC固有というか、ウィンドウズプログラミングにおける考え方というべきか。

例えば、MFCでウィンドウ内に何かを描く場合。
みくみくオセロであれば、オセロ盤を描いている部分。

MFCではクラス別というか役割別にファイルが分割されているので、当然書く場所が決まっている。
具体的には「CView」から派生した「C…View」(…はプロジェクト名)。
なのだが、最初に指定するMFCアプリケーションウィザードでわかりやすいように最小限の指定をするとこのファイルはなくなってしまう。

実際のコーディング段階になってから「あれっ?」ということになる。
まぁこの手の問題は調べれば簡単にわかる基礎的なことが多いので、そんなに問題にはならない。

長くなりそうなので続きは次回。

みくみくオセロをリリースして

2016年8月15日

先日みくみくオセロをリリースした。
その情報が少しずつネット上に拡散しつつあるようだ。

ホームページのアクセス解析をみているとよくわかる。

今の時期、多くの人が休みモードになってるから、普通なら平日の3分の1ぐらいしかないアクセスが…。
おとといなんか平日の2倍近くになってたもんね。

もちろんトップはみくみくオセロのダウンロードページで、それにつられて他のページビューが少しずつ伸びてるかんじ。

そしておかげさまでこのブログのアクセスも少し伸びて…。
コメントまでいただいて感謝!

夜も寝ないで昼寝してがんばったかいがあったよー。
やっぱがんばってきたことが形になって周りから反応があるとうれしい!

さーて、次は何をつくろうかなー。

次回作にご期待ください。