DXライブラリ用ウィンドウ生成クラス

[kazuoni]

お邪魔します。

以前から、たまに「DXライブラリで二窓はできないのか？」
と質問が見受けられました。
解決方法は基本的にはNOですので、なんとかできないかと思い、
自作してみました。まだ未実装の部分ばかりですが、
一度、雰囲気を見てもらい、改善部分または、根本的な修正を提示していただきたく思います。

今回作成する窓は、DXライブラリで生成されるウィンドウ内でしか移動ができません。
はい、要するに二窓ではないんです。。
ウィンドウ画面をちょっとでも効率よく使おうって感じです。
デバッグの際に変数の動きをみるのに使えるかな？程度です。

（正直、管理に当たって、独自のMouseクラスを用いているので
この時点で一般ユーザー向けの作りではないのですが・・・）

今の段階での主な機能は
・ウィンドウのタイトルバー化
・ウィンドウの移動
のみです。今後は、
・閉じる
・ウィンドウの拡大・縮小
・タイトルバーの右クリック対応
などを予定しています。

使用方法は添付したテキストファイルに記述してある通りです。
以前、考えの段階で一度質問をしましたが、結局はウィンドウクラスと管理クラスの
二種類で作成してしまいました。

・このあたりはもっと細分化したほうがいい
・こんな機能があったら便利だろう
・自分だったら～～のように管理するだろう

など何でもよいのでご意見をいただきたいです。
ソースの添付しましたが、解説はほとんどついていないので、
何か説明が必要なところは説明します。

よろしくお願いします。

DL key : kazuoni
http://www1.axfc.net/uploader/Sc/so/91928

[Ma]

目的がちょっと不明ですが、とりあえず不具合

タイトルバーをドラッグで、移動を意図したのにウィンドウ自体が縮小する。

[Justy]

　使う側としては main関数内でこのウインドウの表示の為に WManager::SetDrawScreen()や
DxLib::SetDrawScreen(DX_SCREEN_BACK)を何度も呼んだりして表示をしていますが
このあたりはシステムで吸収する・（ウインドウ内の描画を）コールバックに纏めるなどして、
main関数側では WManager::Draw()の一命令で済ませたいところですね。

　それから keyが各ウインドウのハンドルなのであれば、keyを使ってできる
ウインドウの（位置、サイズなどの）システム情報の取得や設定できる関数を増やすとか。


　あとは問題かどうか断定はできませんが、クラスのメソッド内での static変数が幾つかあるようです。
　これはクラスの生成・破棄をした後、再度生成した時でも正常に動作するよう設計されていると
考えてよろしいですか？


＞デバッグの際に変数の動きをみるのに使えるかな
　それをやるなら（このシステムとは別の設計になるとは思いますが）こんな感じの機能も
あると便利だと思いますよ。
http://www.play21.jp/board/formz.cgi?ac ... 4822#14760

[dic]

こ、これは・・・私が最近javaに浮気をしていることを知っての作成か・・・ｗ

javaだと 利用するだけでいいんだよね
C/C++だと、一から作らなきゃいけないけど、それが楽しかったり苦しかったり

DxLibもバージョンアップしてるんですね

VC6 だと 下のところだけコンパイル通らないですね

WData data1 = { 320, 240, 300, 200, p1, "Chara Para" };
        WData data2 = { 350, 200, 32*c_width, 32*c_height, p2, "Chara Working" };
main.cpp(50) : error C2552: 'data1' : 初期化子リストによる個別の識別子の初期化に誤りがあります。
main.cpp(51) : error C2552: 'data2' : 初期化子リストによる個別の識別子の初期化に誤りがあります。

わたくしごとですが
OSごとに動作管理するの大変なのでjavaにいこうかと考えてるんですよ
98,98SE,2000,NT,ME,XP,VISTA,7...
ＯＳ購入しないといけないし、動作も確認しないといけないし・・・


欲しい機能としては
タイマー機能があったらいいなと思います
タイマーってDxLib側で管理してるのかな？

[kazuoni]

返信が遅れて申し訳ありませんでした。

ご回答ありがとうございます。

Maさん
> タイトルバーをドラッグで、移動を意図したのにウィンドウ自体が縮小する。

確かにその通りでした。
修正しました。ご指摘ありがとうございます。


Justyさん
> WManager::SetDrawScreen()やDxLib::SetDrawScreen(DX_SCREEN_BACK)を
> 何度も呼んだりして表示をしている

これは自分もかなり違和感のあったところです。
ユーザーが画面を切り替えるための手続きが
少しでもDXライブラリっぽくできればいいかなと思い、
あんな醜い形にしてしまいました。
ラップして以下の様にする事にしました。

WManager::Order()->SetDrawScreen(key1,e_IN);
WManager::Order()->ClearDrawScreen();
// 描写等
WManager::Order()->SetDrawScreenBack();

WManager::Order()->Draw();

> main関数側では WManager::Draw()の一命令で済ませたいところですね。

申し訳ありません。「関数WManager::Drawの一命令にする」が想像できません。
例えばユーザーが画面の切り替えの手続きを行うにはどうすればよいのでしょうか？

> ウインドウの（位置、サイズなどの）システム情報の取得や設定できる関数

あ、完全に忘れていました。。
原案の段階ではあったのに、いつの間にか忘れ去っていました。

> クラスのメソッド内での static変数が幾つかあるようです。

よく考えてみれば、とてもよろしくないです。
なるべく使わない方向にもっていきます。
っというか、普通は使わない方がbetterですよね。（？）

> デバッグ関連

個人的にデバッグに特化したウィンドウも別途で作成しようと思っていたので、
大変参考になります。
外部でパラメータ操作でき、プログラマでなくても調整できるというのは
かなり大きなメリットですね。
個人的に「ソフトリセット」に興味があるので、またいずれか
質問させていただくかと思います＾＾；


> dicさん
> こ、これは・・・私が最近javaに浮気をしていることを知っての作成か・・・ｗ

・・・暇だったからですｗ

> VC6 だと 下のところだけコンパイル通らないですね
すみません。。思いっきり環境依存でしたね。
こういうことがちょくちょくあるんです。
今後は-Wallも用いて、環境依存を減らすよう、努力します。

> タイマー機能があったらいいなと思います
御提案ありがとうございます。
（目的にもよりますが）DxLib.hをみる限り、
時間関連に特化している印象はないような気がします。
やはりWINAPIと絡めないといけませんかね。

[Justy]

＞ 「関数WManager::Drawの一命令にする」が想像できません。
＞ 例えばユーザーが画面の切り替えの手続きを行うにはどうすればよいのでしょうか？
[color=#d0d0ff" face="monospace]
WManager::Order()->SetDrawScreen(key1,e_IN);
WManager::Order()->ClearDrawScreen();
// 描写等
WManager::Order()->SetDrawScreenBack();
WManager::Order()->Draw();
[/color]
　この処理の「描写等」以外の処理はすべて定型ではないでしょうか？
　であれば、登録処理(Entry)は勿論どこかで必要になりますが、描画周りの定型的な処理を
システムの方でラップしてしまえば、ユーザーは描写などの部分だけを書けばよくなるかな、と
思ったわけです。

　例えばイメージですが、Ｃっぽく書くならこんな感じでしょうか。
[color=#d0d0ff" face="monospace"><hr width="70%" align="left" color="#101010]
void key1_in_func(int key, void *p)
{
DrawCharaPara(chara.walking_flag==1);
}
void key2_in_func(int key, void *p)
{
RandomWalking();
}

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow )
{
...（略）...
WData data1 = { 320, 240, 300, 200, p1, "Chara Para" , key1_in_func, NULL, NULL, NULL};
WData data2 = { 350, 200, 32*c_width, 32*c_height, p2, "Chara Working", key2_in_func, NULL, NULL, NULL };
WManager::Order()->Entry(data1);
WManager::Order()->Entry(data2);
...（略）...
}[/color]

　WDataに追加されているのは e_IN / e_OUTそれぞれの処理の時に呼び出される関数ポインタと
引数となる voidポインタです。

　指定された関数ポインタなどの情報は WDataの中に入っているので、WManager::Draw()の中で
[color=#d0d0ff" face="monospace"><hr width="70%" align="left" color="#101010]
if(wdata.func_out)
{
SetDrawScreen(key,e_OUT);
DxLib::ClearDrawScreen();
wdata.func_out(key, wdata.func_out_param);
}

if(wdata.func_in)
{
SetDrawScreen(key,e_IN);
DxLib::ClearDrawScreen();
wdata.func_in(key, wdata.func_in_param);
}

DxLib::SetDrawScreen(DX_SCREEN_BACK);

if(win->Draw()!=-1)[/color]

　のような感じで呼び出せばメインループは
[color=#d0d0ff" face="monospace"><hr width="50%" align="left" color="#101010]
while( DxLib::ProcessMessage()==0 && DxLib::ClearDrawScreen()==0 &&
Keyboard::Order()->Refresh()==true && Keyboard::Order()->GetPress(KEY_INPUT_ESCAPE)!=true &&
Mouse::Order()->Refresh() && WManager::Order()->Refresh() )
{
DrawBox(0,0,640,480,0xffffff,TRUE);

WManager::Order()->Draw();
DxLib::ScreenFlip();
}
[/color]
となり、簡潔になるのではないでしょうか。

　こうなると Refleshと Drawも分ける意味があまりないような気もするので統合してしまうといいのかもしれません。

[kazuoni]

またまた返事が遅くなってしまい、申し訳ありませんでした。

なるほど。各ウィンドウにmain関数を持たせるみたいな感じですね。
ということで、早速実装してみました。
これならばユーザーはいちいち手続きを書かなくても済み、
コードも管理しやすそうです。一応、Refreshにまとめておきました。


異なるウィンドウ間で共有する変数の管理方法って大変ですね。。
個人的には、ウィンドウで実行されるメソッド、共有したいメンバ等を
クラスで管理し、他のウィンドウから参照するにはアクセッサでいいのかな
と思いましたが、これだと再利用のためのクラスではなく、
お得意のシングルトンクラスになりそうです。
最近思ったのが、シングルトンクラスって再利用性がないのに頻出していいものなのでしょうか？
個人的には便利で使い勝手がいいような気もするのですが。

[Justy]

＞異なるウィンドウ間で共有する変数の管理方法って大変ですね。。
＞～（略）～
＞お得意のシングルトンクラスになりそうです
　えーと、あんまりよく理解できなかったのですがそこでどうして
シングルトンになってしまうのでしょう？

　単純にウインドウＡにはクラスＡを、ウインドウＢにはクラスＢを作って、
共有するクラスＳをクラスＡ・Ｂにポインタなり参照なりで持たせるだけ、
ですよね？


＞シングルトンクラスって再利用性がないのに頻出していいものなのでしょうか？
　それが本当にインスタンスの個数を制限しなければならない妥当な理由があるのであれば
別に構わないと思います。
　ただグローバル的にアクセスしたいとかが理由であれば、否です。

[Justy]

　あ、あと WManagerクラスの実装はもうちょっとなんとかした方がいいです。

　vectorの１本化とか、ループを整数カウンタでなくiteratorで回すとか、
何回も vec.atでアクセスしないで一時変数に代入してから使うとか、
順番の入れ替えは std::iter_swapが使えないかとか、newした Windowが deleteされていないとかとか。

[kazuoni]

とりあえずご指摘いただいたところを直してみました。
vectorを使い始めたのが最近なゆえ、どの様に扱うのかがイマイチ分かりませんが・・・。

あとvoidポインタもほとんど初めて実装しますが、大変便利な半面、
しっかり仕様を書いておかないと大変なことになりそうです＾＾；

DL key : kazuoni
http://www1.axfc.net/uploader/Sc/so/93358


#追記
メソッド内のstaticの変数がそのままになっていました・・・。
ここはメンバ変数に変更しました。

#さらに追記
ダブルクリックのほうもまだおかしかったので、修正しました。

[lbfuvab]

DxLibってAllocConsole使えませんでしたっけ？
デバッグ用に2窓にするならAllocConsole＋freopenで十分な気も・・・

[kazuoni]

> DxLibってAllocConsole使えませんでしたっけ？

確か使えたと思います。
ただ今回は、一応グラフィック描写も含めたウィンドウを
目標としているので、わざわざ面倒な事をしてます＾＾；

[Justy]

　ウインドウを３枚以上だすと挙動がおかしくなるようです。
　移動した後、別のウインドウを移動しようとすると元のウインドウが移動してしまいます。

　ソースを正しく把握はしていないので推測ですが、ウィンドウの優先順位変更の
if(vec.size()>1)の中って、単純に
iter_swap(vec.begin(),it_vec);
だけでいいような気がするのですが、どうなんでしょう？

[kazuoni]

申し訳ありませんでした。。
ここが明らかにおかしかったです。

else // ウィンドウの優先順位変更
{
    ...
        iter_swap(temp_it_vec,it_vec);
        if(i>=i-1) // ×
    ...

}

else // ウィンドウの優先順位変更
{
    ...
        iter_swap(temp_it_vec,it_vec);
        if(i>=dis-1) // ○
    ...

}

> 単純にiter_swap(vec.begin(),it_vec);
それでも得には支障はないと思いますが、
一応優先順位順にしておいた方が無難かなと思いまして。
0 1 2 3 4 // 3を先頭に
↓
0 1 3 2 4
↓
0 3 1 2 4
↓
3 0 1 2 4

[Justy]

　遅くなりました。

＞一応優先順位順にしておいた方が無難かなと思いまして
　なるほど、確かにそうですね。
　なら代わりに
std::rotate(vec.begin(), it_vec, it_vec+1);
でも同じことができそうな気がします。

[kazuoni]

> std::rotate(vec.begin(), it_vec, it_vec+1);
素晴らしいです・・・。
stdには本当に便利なものがあるんですね。

何度もご回答していただき、本当にありがとうございました。
今回はこれで解決とさせていただきます。
また、ある程度仕上がったら報告させていただきます。
その時はよろしくお願いします。

次回もよろしくお願いします