VisualC#での画面変更の方法

質問

開いていただきありがとうございます。

ちょっと質問の題名が適切か分かりませんが、
VisualStudioでフォームデザイナを用いた場合の話になります。

例えばスケジュール帳を作っていたとしましょう。
そうすると月単位での表示や日単位での表示など、
まったく異なるデザインをひとつのWindowで処理したい場合があると思います。
また、ちょっといい例が思い浮かばないのですが、
ゲームで言えばフィールド画面・戦闘画面・タイトル画面などのように、
役割も用途も違う内容を都合でひとつのWindowで処理したかったりする場合もあったりします。
（ゲームを作るわけじゃないので、あくまでもそれぞれフォームデザイナを使ったとして）
本来ならばダイアログで処理したりする方がいいんでしょうが。

このような場合は、どのように処理するのがよいのでしょうか？
どなたかご教示いただければ幸いです。

ちなみにこれまでCUIベースでいろいろとやってきましたので、
VisualStudioに関する知識は最低限と思っていただければ。

回答No.1

Yune-Kichi · ベストアンサー

ウィンドウの一部を切り替えたい，ということを実現するのであれば，
切り替えたい内容をユーザーコントロールにして，Visibleを切り替えるのが簡単です。
Panelに貼り付けて同じこともできますが，デザイン画面がごちゃごちゃしてしまうため，お薦めしません。

機能をどう表示するのがベストかは，条件によって異なります。
・ウィンドウの一部を切り替える
・タブを使う
・別ウィンドウをモーダルで表示
・別ウィンドウをモードレスで表示
・MDI
等々。

お礼

早速のお返事ありがとうございます。

ユーザーコントロールというものを利用していなかったので簡単に調べてみたのですが、
メイン画面に直接ラベルなりボタンなりを貼り付けてデザインするのではなく、
別途デザインしたもの全体を、ラベルなりと同じひとつの部品として、
必要なものをレイヤー状に重ねて、必要なもののみを表示する……
という解釈であっているでしょうか？

Panelにはりつけるというのは、上記のものをひとつの部品とせずに、
同じフォームデザイン画面の中でグループ分けして表示・非表示を切り替えるため、
規模が大きくなるにつれて画面が煩雑としてきて取り扱いにくいということですよね？

基本的なことしか取り扱っていない書籍＋必要な知識を散発的に検索しているので
全体的な理解が浅くてどうにも申し訳ありません。
皆様MSDNを読破とかされてるんでしょうか……CUIとは勝手が違いすぎて大変ですけれども頑張りたいと思います。

お手数ですが、よろしければ上記の理解で間違っていないか返答いただければ嬉しいです。
それでは、ありがとうございました。

回答No.4

Yune-Kichi

> ユーザーコントロールというものを利用していなかったので簡単に調べてみたのですが、
> メイン画面に直接ラベルなりボタンなりを貼り付けてデザインするのではなく、
> 別途デザインしたもの全体を、ラベルなりと同じひとつの部品として、
> 必要なものをレイヤー状に重ねて、必要なもののみを表示する……
> という解釈であっているでしょうか？

あっています。

ユーザーコントロールは，複数のコントロールをまとめて新たな一つのコントロールにするものです。
# 似た言葉でカスタムコントロールというものがあります。既存のコントロールを継承して新たな機能を追加したものです。

> Panelにはりつけるというのは、上記のものをひとつの部品とせずに、
> 同じフォームデザイン画面の中でグループ分けして表示・非表示を切り替えるため、
> 規模が大きくなるにつれて画面が煩雑としてきて取り扱いにくいということですよね？

はい。

ユーザーコントロールにしてもデザイン時は表示上重なってしまうのですが，
ユーザーコントロールの中身については別途デザイン・実装できるので問題がありません。
ところが，パネルだとあくまでパネルの含まれるフォームやユーザーコントロールのデザインの一部なので，
デザインするのに他のパネルが邪魔になります。

> XAMLとかにも興味はありますが、興味以上の労力を強いられそうなのが現状なので、

XAMLは
・WPF アプリケーション
・Silverlight アプリケーション
・Windows Phone アプリケーション
・Windows 8 メトロスタイルアプリケーション
のUIに使う技術なので，Windows Formsアプリケーションの開発においては使いません。
# XAML自体はUI用の技術ではないのですけどね。

> もしその判断事態が誤りで、例えば描画系クラスがフォームデザイナより楽かもとかでしたら、

通常のアプリケーションでそういう状況になることはまずあり得ません。
そうなるようでしたら，WPFの利用を考慮することもお薦めします。

お礼

回答ありがとうございます。遅くなってしまい申し訳ありません。
解釈はおおよそあっていたようでほっとしております。

ユーザーコントロールとカスタムコントロールと混同していました（汗）。
気を回していただいてありがとうございます。後の混乱がひとつ消えました。

> Windows Formsアプリケーションの開発においては使いません
言葉足らずでしたね。
WPFアプリケーションも考慮しようかという意味で、そのあたりは理解しております。
ひとまずはUIを組む程度だから無理にWPFを使わなければいけない必然性はなさそうなので、平易な資料も少ない現状で無理はしない予定です。

回答No.3

MARU4812

> 可能な限り楽をしたいという次第です。
プログラムをする人はそうであるべきだと思います。
ただ、学習してスキルを習得出来ないからではなく、
高度なスキルを用いて効率化・自動化を図るのが
プログラマだからです。
プログラマは「手を抜く」目的の為なら「労力を
惜しまない」という一見矛盾した中に注力できる
人が向いていると思います。

> もしその判断事態が誤りで、例えば描画系クラスが
> フォームデザイナより楽かもとかでしたら、
> よろしければそのあたりの詳細を教えていただければ助かります。
質問文でゲームを例えに出されていたので、
「30×30のドット絵を描く必要があったとき」
・ボタンコントロールをきれいに30×30個並べて1個1個背景色を設定していく。
・描画系のクラスで30×30の点を描く。
のどちらが楽かと言われれば明らかに後者です。

既製品は、お手軽ですが、本当に細かいところに
こだわった時に対応し切れません。これに対し、
全てオーダーメイドで行なう技術は、要求が
あるレベルを越えた時点で、圧倒的な力を発揮
する事があるということです。

お礼

回答ありがとうございます。遅くなってしまい申し訳ありません。

その辺りは身にしみて理解している……つもりです（汗）。
存外どの書籍も似たり寄ったりの内容が多いみたいなので、
当面はフォームデザイナに寄りかかりながら、ひとつずつ疑問を潰していく程度のつもりです。
他にもっと注力したいことは山とありますからね。

またどうしても解決できない点などあれば、どうぞよろしくお願いいたします。

回答No.2

MARU4812

技術的にはフォームもコントロールの機能を持っているので、
フォームの上にフォームを乗せられます。
http://dobon.net/vb/dotnet/form/formwithinform.html
MIDIは
http://dobon.net/vb/dotnet/form/mdiapplication.html

描画系のクラスを使って自分でお絵かきする事もできます。
結局、ディスプレイの表示色を変更しているだけですから。
本当にボタンという部品が出来ているわけでなく、すべて
仮想の電子データしかないわけですので、それらしく錯覚
させられるならそれでもいいわけです。

お礼

返答ありがとうございます。
お返事おくれてしまい済みません。

ちょっと風邪を引いてしまいリンク先を精読とまではいかないのですが、面白そうではありますね。
落ち着いたら関連記事も含めていろいろ眺めてみたいと思います。

個人的なこととしましては、
描画系クラスでそれっぽく見せかけたりとかできるということは承知しているのですが、
GUI部分にあまり手間をかけたくないというか、正直書いててあまり面白みを覚えないので、
可能な限り楽をしたいという次第です。

XAMLとかにも興味はありますが、興味以上の労力を強いられそうなのが現状なので、
素直にフォームデザイナを活用できるようになるのが得策かなと判断しました。
もしその判断事態が誤りで、例えば描画系クラスがフォームデザイナより楽かもとかでしたら、
よろしければそのあたりの詳細を教えていただければ助かります。

それでは、推敲する余力がちょっとないので乱文気味申し訳ありませんでした。