What's new

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

2016年8月30日

やっと最後の3つ目。

今までのはぶっちゃけ前置きみたいなもので、今回が一番大事だ。
なぜなら今までの2回というのは、目が見えていようとそうでなかろうと主に知識不足という悲しい原因がもとで起こってしまう事故みたいなもの。

でも今回は違う。
目が見えていれば数分で解決することが、目が見えていないばっかりにかなりの時間を費やしてしまった話をしよう。

それは、ウィンドウズからなんらかのメッセージを受け取れるようにプログラムを作ろうとしたとき。

具体的には…。
前回書いたようなユーザーがメニューを開こうとしているときとかに、ウィンドウズからみくみくオセロに「メニューが開かれようとしているよ」というメッセージが飛んでくるのだ。
こいつをうまくキャッチしないとメニューを自由に変更することができない。

ということは、コーディングする際にも
「この部分のプログラムは、ウィンドウズから送られてくるメッセージをキャッチして動く部分だよ」
という手続きを踏まなくてはいけないことになる。

そしてこの手続きをする部分というのがやっかいなのだ。

具体的には、クラスウィザードという専用ツールを立ち上げて、目的のメッセージとそれを受けるプログラム名を選んで関連付ける処理をさせる。
しかし目が見えていない場合、当然スクリーンリーダーでクラスウィザードを読み上げさせるのだが、これがうまく読み上げてくれないのだ。

目が見えていれば何回かマウスの左クリックをするだけでできてしまうらしいのだが…。
ぼくみたいな目の見えていない人間の場合は、ほかの方法を試みるしかない。

まぁでもこのあたりまでは目の見えない生活を10年以上やっていれば普通に起こることなので、そんなにへこむことではない。

しかし問題はここから。
ほかの方法を探そうとネット検索をしたのだが、出てくるページ出てくるページすべて「クラスウィザードを使いましょう!」ときたもんだ。
「おまえらそろいもそろってクラスウィザードの手下かよ!」
と突っ込みを入れたくなるぐらいだ。

そんなわけで手動で何とかする方法なんて載ってなかった。
正確に言えば、ぼくが見つけられなかっただけなのかもしれないが…。

きっとよっぽどクラスウィザードが便利なのだろう。
それにそもそも手動で何とかすることは不可能なのかもしれないというあきらめモードにもなりかけた。

しかし、本家マイクロソフトのページの奥深くに書いてあったのをやっと見つけた。
そのページにしたがってコーディングし動かしてみた。

そうしたら動いたのだ。
やった!
自力で壁を乗り越えたのですごくうれしかった!

実は今回書いたことは、以前すでに書いている。
そのときは、マウスの左クリックを認識させるというような内容で書いているので興味がある人は探してみてほしい。

話は戻るが…。
そのページには心強いことに、マイクロソフトは作成するアプリケーションの設定などはなるべくプログラム上に記述することが望ましいと考えていることもわかった。
なぜならプログラム上に記述したほうが、それを書き換えるだけで簡単に変更ができ、結果柔軟なプログラムができるのだ。

さすが泣く子も黙るマイクロソフト。

ぼくのような視覚障害者のためではなかったが、プログラム上に書いてくれるのであれば…。
そこから設定を理解したり、変更したりできる。

VisualC++は正直、スクリーンリーダーでは使えない部分もあるが、今回工夫しだいである程度は何とかなるものなのだということを体験できてよかった。

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倍近くになってたもんね。

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

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

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

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

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

みくみくオセロ公開

2016年8月12日

ブログを書くのも久しぶり。

開発でドタバタしていてブログ更新どこじゃなかった。
まぁでもそのおかげで、とりあえず完成。

みくみくオセロ

http://kimurashuuichi.com/visualstudio/application/osero.html


オセロゲーム。
しかも初音ミクによるガイド付。

セールスポイントは、全盲でも楽にプレイできるように工夫したとこかな。

全盲でオセロをやる場合、何がたいへんかといったら…。
そりゃ常に変化するオセロ盤の状態をどうやって把握していくかということ。

1マスずつ動いて確認するなんてバカバカしいでしょ。
つかれるし、罰ゲームじゃないんだからそんなことやってらんないでしょ。

だから指定した位置から上なら上のライン、左斜め下なら左斜め下のラインをまとめて確認できる機能をつけてみた。

開発はたいへんだったけどなかなか楽しかった。