スポンサーサイト

一定期間更新がないため広告を表示しています

- | - | -
タブコントロールは人気がない?
 MFCの話。

タブボタンのついた画面を作成する時に、


MFCではタブコントロールと、プロパティシートの二つが用意されているようです。

タブコントロールと言うのは、画面そのものではなく、
画面に張り付いているタブボタンのみですね。
それに対して、プロパティシートの方は画面そのものです。

見た目上でのタブボタンとの大きな違いは、作成する人が用意する画面の数。


タブコントロールの方は、
・タブコントロールを貼り付ける大元の画面
・タブコントロール
・タブボタンで表示させたい画面
で作成します。(後はお好みでOKボタン等。)


プロパティシートの方は
・タブボタンで表示させたい画面
のみが必要です。(OKボタン等が必要な場合は表示させたい画面全てに必要?)
プロパティシートの方は、
大元の画面や、タブコントロールを自動で生成してくれます。
そのため、表示させたい画面のみで十分なのです。

これだけ見ると、「プロパティシートの方が楽じゃん。」って思います。
実際に動くようにするのに関してもプロパティシートの方が断然楽です。

これだけどちらが便利なのかが歴然で、何故この話をするかと言うと、
プロパティシートには制限事項が多いから。

タブコントロールは基本、大元の画面を作る時に、
タブで表示させたい画面も作ると思います。
それに対して、プロパティシートは、大元の画面を作る時に、
一番最初に表示させる画面以外は作られないのです。
タブコントロールが「作る」に対してプロパティシートが「作られない」と言っているのは
タブコントロールの方は、意図的に作成しなければいけないのですが、
プロパティシートの方は自動で作成を行うためです。
勿論、二つとも互いの動きを真似ることはできますが…。

プロパティシートは、最初に表示させる画面以外は、そのタブボタンが押され
画面が表示される直前で作られます。
そのため、全ての画面から情報を表示しようとする等の処理を行って、
まだ存在していない画面を見ようとすると、プログラムが異常終了します。
そこを上手く抑止するための工夫が必要となるわけです。
(画面が開かれたかどうかのフラグで情報の取得を抑止するとか…ね。)

それに、大元の画面を自動で作成されてしまうため、プロパティシートは
大元の画面が自動で作成されてしまうため、レイアウトは完全に固定となってしまいます。
(タブコントロールとタブボタンによって表示される画面、OK・キャンセル等のボタンだけ。)
また、ボタンについても、「適用」等が自動で用意されてしまうため、
見えないようにする工夫が必要です。

個人的に感じる、プロパティシートの一番の問題は、
画面間の情報のやり取りが困難な事でしょうか。
タブボタンで表示させる画面の中に、他の画面の情報と連動しているものがあるとします。
これから表示させる画面をA、
Aで表示させる情報と連動しているものを持っている画面をBとします。
Bを変更した後Aを表示した場合、どうやってAの情報を反映させればいいのでしょう。

タブコントロールの場合、
タブコントロールを持っているのが大元の画面であるため、タブボタンが押された時に
本来の動作(押されているタブを変更する。)に対して割り込みや抑止を行わせる事ができます。
このタイミングでBの情報を取得する→Aの画面に取得した情報を設定する。
と言う処理ができるのです。

プロパティシートの場合、タブコントロールを持っていません。
そのため、大元の画面がタブコントロールのような動きをすることができないのです。
ぱっと思いついて解決方法が以下の二つ。
・無理やりプロパティシートにタブコントロールを実装する(未確認)
・プロパティシートに対して無理やり取得と設定処理を行わせる。(恐らく可能…。)
省略しますが、1のやり方では限りなくタブコントロールと処理が類似し、
2のやり方はかなり強引(設計上よろしくない)作りになると思います。
(1については、イベントハンドラにプロパティシート(一応持ってる)の持ってるアドレスが参照してるタブコントロールを設定すればいけるんじゃないかなぁ…と思う。)

プロパティシートにはこういった制限があるにもかかわらず、
「タブコントロールは使えない。」「まっとうなVCプログラマはこんなの使わない」「こんなの使うのはにわかMFC屋」とか言われてるのはどうなのだろうか……。
そしてこれらの理由が「タブコントロールは貧弱」とか。
どう見ても、プロパティシートの方が設計上で問題になりそうなのだが……。


ただ、職場ではプロパティシートが好まれる。
その理由は、「タブボタンを押した時の画面のフォーカス(どの項目が選択状態になるか)の遷移がおかしい」からである。(マウスで大元の画面を選択したか、タブボタンによって表示している画面を選択したかによって、大元の画面内でのみ遷移したり、表示している画面内でのみ遷移したりする。)
……成る程納得。
これは悲しい。
開発・設計とかプログラミングとか。 | comments(1) | -
旅中毒
 あのトンネルの先には何があるんだろう。
次に目が覚めた時には何処に着くんだろう。

一人旅のあの瞬間がたまらなく好きです。
帰ってくる時も、見慣れた風景に戻る懐かしさのようなものと寂しさが混ざったような感覚になるのも好きです。

どうも連休が無くて一人旅に出にくい…。
8月のお盆休みは予定が入ってしまっているのですよねぇ。(のでコミケもお休み。)
4連休位あると落ち着いて2泊3日でふらっと行けるのですが。
(1泊2日は微妙。土日でやると過酷。)

東方の音楽を聴いていたら、急に旅に出たくなった。
今度は出雲の方か、伊勢の方へ行きたいのですが。
果たしていつになるのやら……。

守屋神社と浅間大社の奥の方へも行きたいのですが、現状両方とも。
守屋神社は徒歩で行くには無謀すぎます。恐らく往復で半日使うんじゃないでしょうかね。
足が無いと…(タクシーは1万超えるらしい…非現実的すぎる。)
浅間大社の方は富士山のてっぺんですからね。ノリで登ろうとして大騒ぎを起こされた方の二の舞にならないように注意しないと。

ああ、紀行も書かないと。
日常あれこれ | comments(0) | -
goto文は使うべからず?
音信不通気味な上に、 
どうにも専門的なブログになりつつあります。
書く気がどうにも起きなくて……。

と言うわけで、C言語等で
「使ってはいけない」と教わる人も居るgoto文です。
内容としては「○○○:」と書かれている行(ラベルって言うみたいですね。)に向かってジャンプすると言ったところでしょうか。

「間の処理命令を全て無視」するだけでなく、本来の「上から下へ一つずつ処理する」といったルールを無視する事も出来る命令文です。
つまり

○○○:

省略

goto ○○○

と記述すると、「省略」となっている処理を無限に繰り返す文が出来上がります。
そして最初に触れましたが、使ってはいけないと言われているのは「上から下へ一つずつ処理する」というのを無視できるのもありますし、何より…

goto △△△
○○○:
処理4
goto  EXIT

×××:
処理2
goto □□□

△△△:
処理1
goto ×××

□□□:
処理3
goto ○○○

EXIT:
終了

こんな書き方された日には自分は間違いなく暴れだします。
ただ、「間の処理命令を全て無視」という所はポイントだと思うのですよ。
例えば

x = 10;
flg = 0;
「xが1以上の場合括弧を繰り返す」 {
    「flgが0」 {
        処理1;
        「処理1は成功」 {
        
        } 「処理1は失敗」 {
            flg = 1;
        }
        x = x - 1;
    }
}

終了

あまり良い例ではないですが、この例だと
flgって言うのが0の間処理1はするけど、
処理1を一度でも失敗したらflgを1にする。
flgが1になったら処理はしない。
って感じですね。これを10回繰り返すのですが。

これ初回で処理1失敗したとすると、残り9回は何もしない処理が続きます。
何もしない処理が9回も続きます……。
こういう時に

x = 10;
「xが1以上の場合括弧を繰り返す」 {
    「flgが0」 {
        処理1;
        「処理1は成功」 {
        
        } 「処理1は失敗」 {
            goto EXIT;
        }
        x = x - 1;
    }
}

EXIT:
終了

と書くと、最初で失敗した場合残り9回の処理をせずに終了の手前まで飛んでくれちゃいます。
まぁ、上の例だと「break」でいいじゃん…。なんて思われてしまいますが。

ループの間に長々と処理があったり、その処理の失敗が致命的なエラーであり、処理を継続させてはいけない時等には、下手に分岐文で逃げ道を作るより終了処理直前までgotoで飛ばしちゃった方が文章が複雑化せずにスッキリと書けます。
終了処理にはいいんじゃないかなぁと思ったりしちゃったのでした。
開発・設計とかプログラミングとか。 | comments(0) | -
CListViewが見つからない?
 ちょっと会社のお仕事でのお悩み。

あんまり話していい内容ではないので色々な愚痴なんかは伏せますが。
(元にしてるプログラムのソースが理解できる程に腹が立ってきて、
最近は怒りを通り越して腹筋が苦しくなってきてるところ。)
そんな現状報告はどうでもいいのですがね。

で、MFCを使ったGUI作りなんですがね。
元のプログラム通り、実装してみた所リストビューが見つからないとかって
コンパイルエラーで怒られるんですよね。
ちょっとした宿題としてその日は帰ったんですけど。
今思い返すと、リストコントロール周りの実装とか作成の指示って何処が出してるんだろう…
って感じですね。
ソースコードもって帰れないので、会社でまた調べてみるかなぁ。
結構腹筋が苦しくなる程無茶苦茶(と感じる)な事をやっているソースコードなので
案外無いかも知れない…。
無いけれど、何らかの処理で実装してる可能性がある。

今の時代、小難しい事をやるプログラムなんてウケが悪いだけなんですよねぇ。
(組み込み系の場合は、処理や容量を減らすためにたまに難しい事をするんでしょうけど。)
プログラムの流れがあっちに行ったり、こっちに行ったりするようなプログラムなんて
今時きっと流行らないですよ。
最悪は新規で作っちゃおうな流れになるのですが、いかんせん時間に余裕が無い。
(かなりあたふたしてる状態)
果たして間に合うかどうか…。
開発・設計とかプログラミングとか。 | comments(1) | -
むむむ…
 もういくつ寝たんだろうか。
お正月も真っ青な程に通り過ぎてました。

書きたいネタもあるにはありますが、
どうにもコンピュータ言語とかオブジェクト指向が混ざる話なので
まぁわかる人向けですな。

やりたい事は沢山あると言っているけど、このままでは
ロクに何もできずに終わってしまいそうだ。


twitterなんかも面白そうなんですけどね。
仕事中は遊ぶ所か、ネットサーフィンも調べ物以外できないので
mixiとmixiのボイスで十分。

日常あれこれ | comments(0) | -
Recent Comments
Search this site :