ウィンドウクラスの指定について

質問

いつもお世話になっていますGedankenです。
ウィンドウズプログラムについて素朴な質問があります。

Win32 API プログラミング(Ｃ言語)ではRegisterClass などで登録した
ウィンドウクラスをCreateWindow を使う時"文字列"で指定すると思いますが
なぜそんなに回りくどいことをするのでしょうか。

普通に考えれば構造体へのポインタなどで指定した方がスマートだと
思うのですが、どうなのでしょうか。

多分ちゃんとした理由があると思いますが、そこについて解説お願いします。

よろしくお願いします。

回答No.4

sakusaker7 · ベストアンサー

> ここの部分がちょっと分からないのですが、システムがそれぞれのウィンドウクラスを
> 把握する必要があるのはどうしてですか？やはり、プロセス同士の連携でしょうか。
> そこらへんの理由を教えていただきたいです。

アーキテクチャがそうなっているから。という答えじゃだめですかね?
たとえばWindows以外のWindowシステムの例として X (X Window System)と
Macintosh (Classicのほう)を考えてみましょう。

たとえばごく単純なMac用のプログラムは以下のような感じになります。
void main(void)
{
　　WindowPtr a_window;
　　PicHandle picture;
　　Handle a_menu;
　　Rect pict_rect;

　　ToolboxInitialize();

　　a_menu = GetNewMBar(128);
　　if(a_menu == NULL) ExitToShell();
　　SetMenuBar(a_menu);
　　DrawMenuBar();

　　a_window = GetNewCWindow(128, 0, (WindowPtr)-1);
　　picture = GetPicture(128);

　　pict_rect.top = 10;
　　pict_rect.left = 10;
　　pict_rect.right = pict_rect.top + 50;
　　pict_rect.bottom = pict_rect.right + 50;

　　SetPort(a_window);
　　DrawPicture(picture, &pict_rect);

　　EventLoop();

　　DisposeWindow(a_window);
　　ReleaseResource((Handle)picture);
}

void EventLoop(void)
{
　　EventRecord loop;

　　while(1){
　　　　if(WaitNextEvent(everyEvent, &loop, 0, 0L) == true){
　　　　　　switch(loop.what){
　　　　　　case mouseDown:
　　　　　　　　if(MouseEvent(&loop) == QUIT) return;
　　　　　　　　break;

　　　　　　case autoKey:
　　　　　　case keyDown:
　　　　　　　　if(KeyEvent(&loop) == QUIT) return;
　　　　　　　　break;

　　　　　　case updateEvt:/*アップデートイベント*/
　　　　　　　　EventUpdate(&loop);
　　　　　　　　break;
　　　　　　}
　　　　}
　　}
}

もうひとつ、X での例を挙げるとこう。
main(int argc, char **argv)
{
Display *mydisplay;
Window mywindow;
GC mygc;
XEvent myevent;
XSizeHints myhint;
int myscreen;
unsigned long myforeground, mybackground;
int n;

// Ｘサーバに接続する 　
mydisplay = XOpenDisplay("");
myscreen = DefaultScreen( mydisplay );
// Ｘサーバで使用されている基本色を得る
mybackground = WhitePixel( mydisplay, myscreen );
myforeground = BlackPixel( mydisplay, myscreen );
// ウィンドウの位置、大きさを指定
myhint.x = 200; myhint.y = 200;
myhint.width = 300; myhint.height = 200;
myhint.flags = PPosition | PSize;
// ウィンドウを生成
mywindow = XCreateSimpleWindow ( mydisplay,
　　　　DefaultRootWindow( mydisplay ),
　　　 myhint.x, myhint.y, myhint.width, myhint.height,
　　　　 5, myforeground, mybackground);
// 生成したウィンドウの情報をシステムに知らせる
XSetStandardProperties( mydisplay, mywindow, hello, hello,
　　　　 None, argv, argc, &myhint );
// グラフィックを描くための準備
mygc = XCreateGC( mydisplay, mywindow, 0, 0);
XSetBackground( mydisplay, mygc, mybackground );
XSetForeground( mydisplay, mygc, myforeground );
// 受け取るイベントの選択
XSelectInput( mydisplay, mywindow,
　　 ButtonPressMask | ExposureMask );
// ウィンドウを表示
XMapRaised( mydisplay, mywindow );
// イベントループ
n = 0;
while ( n < 10 ){
　　　　　　　　// イベントの取り出し
　　 XNextEvent ( mydisplay, &myevent );
　　 switch ( myevent.type ){
　 // 再描画要求
　　 case Expose:
if ( myevent.xexpose.count == 0 ){
　　 printf("repaint\n");
　　　　　 XDrawImageString(
　　　　　　　 myevent.xexpose.display,
　　　　　　　 myevent.xexpose.window,
　　　　　　　　 mygc,50,50,
　　　　　　　　 hello, strlen (hello) );
　 }
break;
// マウスのボタンが押された
　　 case ButtonPress:
　 XBell( mydisplay, 0 );
　　　　 printf( "button down %d \n", n++ );
　　　　　 break;
}
}
XFreeGC(mydisplay, mygc); // コンテキスト解放
XDestroyWindow(mydisplay, mywindow); // ウィンドウの破棄
XCloseDisplay(mydisplay); // 接続の解除
exit (0);
}

Windowsを含めてこれら三つのウィンドウシステムを考えたとき、XとMacは
イベントループはユーザープログラム自身が制御しています。

>　　EventLoop();
この関数の中身でやっていることとか、

> while ( n < 10 ){
> 　　　　　　　　// イベントの取り出し
> 　　 XNextEvent ( mydisplay, &myevent );

このループでやっていることです。ところがWindowsに関しては

LRESULT CALLBACK WndProc(HWND hwnd , UINT msg , WPARAM wp , LPARAM lp) {
if (msg == WM_LBUTTONUP) {
MessageBox(hwnd , TEXT("終わるにゃん") ,
TEXT("Kitty") , MB_ICONINFORMATION);
exit(0);
}
return DefWindowProc(hwnd , msg , wp , lp);
}

のような、システムから呼ばれる(コールバックされる)形をとっています。あるウィンドウクラスのコールバック関数はただひとつですから、
両者の対応をシステムが把握していなければならないというわけです
(=RegisterClassで登録する)。

わたしはWindowsのアーキテクトでもなんでもありませんから推測しかできませんが、
おそらくこのような形にすることで同じウィンドウクラスのイベントループ処理の
ルーチンをひとつにまとめることができるので、このような形にしたのではないかと思います。
Windows 1.0とかだとメモリ要求もきついですからね。
Macintoshも初期はそれほどメモリが潤沢に使えなかったと思いますが、
非常によくできたROMルーチン(toolbox)がありますからその点でアドバンテージがあります。

C言語によるMacintosh Toolboxプログラミング～
http://delegate.uec.ac.jp:8081/club/x68/press/2001/lecture/mac_toolbox.html

ウィンドウの表示
http://homepage3.nifty.com/rio_i/lab/xlib/001window.htm

http://wwwdoi.elec.nara-k.ac.jp/html/jisyu/xprg/index.html

ウィンドウプロシージャ
http://wisdom.sakura.ne.jp/system/winapi/win32/win10.html

マイナーなところだと、X 68000というパソコン用の SX-Windowとか
Ko-Windowとかいうのもありますが、まあ興味があったら調べてみてください。

お礼

sakusaker7さん、再びの回答ありがとうございます。
また、お礼が遅れて申し訳ないです。

この説明で、よく理解できました。
いつかまたお世話になるかもしれませんが、よろしくお願いします。

回答No.3

sakusaker7

構造体へのポインタが使えないのは、システムにおける一意性が確保できない(保証できない)からでしょう。

それと、登録したときのプロセスが(UnregisterClassをしないで)消滅したときの
処理が簡単になるからではないかと思います。

RegisterClass/RegisterClassExの説明をよく読んでもらいたいのですが、これらの関数は
> 関数が成功すると、登録されたクラスを一意的に識別するアトムが返ります。
> このアトムは、CreateWindowEx 関数、CreateWindowEx 関数、および
> UnregisterClass 関数でしか使用できません。

とあります。内部的にはAtom(システムでひとつしかない文字列テーブル)としてRegisterClass/RegisterClassExに渡されたクラス名を
登録しています。

一意性を確保した上で、たぶんメモリの節約を主な理由として
RegisterClass→CreateWindow という手順をとるようにしているのではないかと思います。

Windows 1.0だの2.0だのの時代のプログラミングはさすがにやっておりませんので
詳しくはわかりません。

お礼

sakusaker7さん、回答ありがとうございます。

>構造体へのポインタが使えないのは、システムにおける一意性が確保できない(保証できない)からでしょう。

ここの部分がちょっと分からないのですが、システムがそれぞれのウィンドウクラスを
把握する必要があるのはどうしてですか？やはり、プロセス同士の連携でしょうか。
そこらへんの理由を教えていただきたいです。

回答No.2

noname#30727

ウィンドウメッセージはプロセス間通信の一種なので、ウィンドウプロシージャがウィンドウを作成するプロセス上に存在しない事もありえます。
他のプロセスのメモリにはアクセスできないので、この仕様は仕方の無いところです。

お礼

inthefloiさん、回答ありがとうございます。

違うプロセスからも使えるようにプログラムがOSにウィンドウクラスの
登録を頼んでいる、みたいな感じですかね。
ポインタは違うプロセスでは使えないですし。

少し理解できた気がしました。

回答No.1

Oh-Orange

★ちゃんと解説できるか不安ですが、私なりのとらえ方を記述します。
・通常、ウインドウクラスは１つしか RegisterClass で登録しなかったり、CreateWindow でも
　１つのメイン・ウインドウしか作りませんよね。→小規模では。
　この場合では、管理構造体を引数で渡した方が確かにスマートかもしれません。
・でもね。ボタン、リストボックス、コンボボックス、エディットボックスなどなども Windows では
　１つの子ウインドウとして管理しています。そして、ダイアログ・アプリケーションで電卓ソフトを
　作ったとすると『ボタン』という子ウインドウをたくさん作りますよね。
　でもたくさんの『ボタン』は押されたときに、親ウインドウに WM_COMMAND などを通知しますが、
　この仕組みはすべてのボタン・コントロールで同じになります。すると同じ管理構造体を多数定義して
　引数に渡すのは面倒ですし、管理構造体が増えすぎます。ここを１つの共通に出来れば、処理も１つに
　できます。そして、１つの処理にするには最初に管理構造体のようなものを登録する必要があるのです。
　これが RegisterClass 関数で登録するウィンドウクラスと思えば分かりやすいと思います。
・１つのクラスに１つのプロシージャしか関連付けれませんが、同じクラスを持つ『ボタン』のような
　コントロールを独自開発した場合、最初に独自コントロールの登録をすれば、それに関連付けられた
　プロシージャを呼び出すだけですべての処理を共通に出来ます。→とても便利です。
・１つのプログラムで複数の独自コントロールを使い、かつ複数の同じコントロールを使う場合には
　最初にウインドウクラスを登録して、それ専用のプロシージャを関連付けれることで処理コード部も
　削減(圧縮)にも繋がります。
・中規模や、大規模のプログラムでは、独自コントロールなどを開発して使ったりしますので、標準の
　ボタン、リストボックス、コンボボックス、エディットボックスも自前で作るときには、どうしても
　RegisterClass 関数の仕組みがないと Windows ではボタン１つでさえも上手く管理できません。
　私はウィンドウクラスの登録や、それに対するプロシージャの関連付けなどの仕組みが、GUI プログラムの
　利点だと考えています。

余談:
・MS-DOS 時代に作成していたソフトも同じ考えを取り入れていれば、もっと効率の良いプログラミングが
　出来たことでしょう。今、思うと懐かしいです。
・以上。私なりのとらえ方でした。→参考に。

お礼

Oh-Orangeさん、大変詳しい回答ありがとうございます。

汎用性の高い設定を構造体にして使いまわすという"ウィンドウクラス"の
仕組みは分かるのですが、なぜ RegisterClass という関数を使って"登録"する
のかが分かりません。

つまるところ、RegisterClass が何をやっているのかが知りたいです。
そこの所を教えて下さるとありがたいです。

よろしくお願いします。