- - PR -
vb.net windows applicationについて
«前のページへ
1|2|3|4
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-02-16 00:45
継承クラスですよね。だから、派生するクラスはひとつではないですよね。
ひとつのFormに、人を引数にしてメニュ−の構成を変更するメソッドを設けるとか。 | ||||||||
|
投稿日時: 2005-02-16 10:12
#あくまで想像ですけど…。
例えば「人事・給与システム」のようなもので、組織編成や発令、勤怠管理に給与処理、個人情報の管理に運用管理など、機能毎にフォームが別であり(普通ですよね)、なおかつログインするユーザー毎に「メニュー画面(きっとボタンが幾つか並んでいる)」から呼び出せるフォームの種類も数も可変である…というよなモノを作っているんじゃないかと。 で、メニュー画面のボタン(?)クリック時に、DBから取得した「フォーム名」を基に、どうやって目的のフォームを開いたら良いのか、を考えていたんじゃないでしょうか。 | ||||||||
|
投稿日時: 2005-02-16 10:20
いやいや、にっしーさんが使った「派生するクラス」という言葉は、いままでの流れからみて「基底となるクラス」の単なる書き間違いでしょう。 それにJittaさんの方法は、にっしーさんの要件の意図とは外れていると思います。 画面を構成しているパーツを自由に配置したいのではなく、メニュー画面のボタンに表示される機能を表す文字やそのボタンを押した時に起動される画面を人によって変えたい(カスタマイズしたい)ということでしょう。(にっしーさんの2005-02-15 12:01の書き込み) にっしーさんが「ランダム」という言葉を用いたのも、誤解を招く原因になっていると思いますが。本当にランダムでは、ボタンを押した時に何の画面が開くか、起動するまで判らないことになってしいまいます(汗 自分もユーザーによってメニューの内容を変更するモノを作ったことがありますが、自分は設定情報をXMLに持ちました。にっしーさんの場合はDBってことです。 方法は、きくちゃんさんが書いた方法(2005-02-15 13:51書き込み)で解決していますが、文字列によりクラスインスタンスを生成したり、メソッドを呼び出したりするのは、他の方も書かれているようにリフレクションという技術を調べてください > にっしーさん。 ひとつのプロジェクトで今はやっているようですが、多人数で開発したりするとプロジェクト(アセンブリ)を分けた方が都合がよくなってくるので、Assembly.Load()等が必要になってきます。 うまく基底クラスやインターフェイスを設計すれば、たつごろーさんが(2005-02-15 11:33)の書き込みで指摘しているようなことにはならないと思いますよ。 (メニュー側が認識する型やインターフェイスはひとつで済むはずですし、基底クラス側に共通処理をもっていけば、処理が分散することもないでしょう) | ||||||||
|
投稿日時: 2005-02-16 12:01
皆様。ご回答大変ありがとうございます。
自分の発言した内容で誤解を招いてしまいまして 大変すみませんでした。( ̄へ ̄゜) 引用: -------------------------------------------------------------------------------- メニュー画面のボタン(?)クリック時に、DBから取得した「フォーム名」を基に、どうやって目的のフォームを開いたら良いのか、を考えていたんじゃないでしょうか。 -------------------------------------------------------------------------------- きくちゃんさん、noderaさんの意見が自分の思っていたことに一番近いです。 上記の内容に加えてDBを参照してメニューの画面のボタンを構成(表示、非表示)するということです。 メニュー画面は完成しましたが もう少しリフレクションについて調べてみたいと思います。 jittaさん、わざわざサンプル等を掲載して頂きありがとうございました。 今後のことも考えて参考にさせて頂きます。 皆さんの意見を聞いてすごく参考になり、勉強になりました。 考え方も人それぞれでいいですね! 本当に正しいやり方ってどんなんだろう?って考えさせられます。 ありがとうございました。 | ||||||||
|
投稿日時: 2005-02-16 20:56
あらら。本人から指摘があるかと思っていたのですが(^o^; 確かに、質問の主題である『動的にクラスインスタンスを生成する』ことからは外れていますが、その質問の要件である『人によってメニュ−の構成を変更したい』からは外れていないと思います。 例示したのは位置だけですが、Visibleプロパティを使えば非表示にだって出来ます。その伏線としての":Location"だったのですが(^o^; つまり、定義ファイルには必要になるであろうすべてのコントロールを定義しておき、必要なら画面に出す、あるいはオブジェクトを生成するようにすれば、問題ないですよね。要はユーザがアクセスできるかどうか、です。ボタンの位置と表示/非表示を切り替えることによって、『単に外見を変えたいだけ』にまで、仕様を整理することが出来るのではないでしょうか。何もコントロールの機能そのものを入れ替える必要はない、と思います。 # 『単に外見を変えたいだけなら』が誤解させたかな 設定ファイルの作成にちと骨が折れますが、フォームを設計する手間を考えれば同じだし、下手に継承だリフレクションだとするより、敷居が低いと思います。それに、フォームの設計はもうできあがっているらしい? 継承、インタフェイスを使うことによるソースの分散に対する難点は、たつごろーさんのご指摘通りです。開発者がメンテナンスしなければならないファイルを増やす必要はないと思います。 対して、フォーム上に配置されるコントロールの位置のみ、外部から指定するようにしてあれば、機能そのものに対する修正は、1ヶ所のみ修正するだけですみます。コントロールの配置を換えるとき、異動によって表示しなければならないコントロールが変わるときも、コンパイルし直す必要はありません。設定ファイル名がデータベースにあるなら、設定そのものをデータベースに格納することも可能なはず。そのようにすれば、わざわざファイルを配布する必要もなくなり、 「誰々さんのところでこのメニューが出ないよ」 「え〜?開発機にはちゃんとでてるよ?」 「ごめ〜ん、最新取ってなかったm(..)m」 なんてこともなくなり、後々のメンテナンスがかなり省力化できると思います。 いや、人それぞれ複数のまったく違う機能を使う、というのなら、話は別ですよ。例えば40人がそれぞれまったく異なる10機能を使うとか。 _________________ | ||||||||
|
投稿日時: 2005-02-17 15:07
Jittaさん、こんにちは。
まさしく、そういう事をやろうとしていると私には読めたのですが…。 1)メニュー画面はひとつ。 2)必要な機能(=フォーム)は約40あり、その組み合わせはユーザーにより異なる(DBにその情報を保持)。 3)ログイン(?)したユーザー毎の設定に基づき、メニュー画面に並んだボタンに、必要な機能の呼び出しを割り当てる。 要は、ランチャですね。それぞれの画面が別のEXEであれば、ファイル名を指定した呼び出しをそれぞれのボタンに割り振るのは簡単ですけど、同一プロジェクトなので、さて、どうやったらスッキリするだろう? という話のようです。 で、それぞれの機能がそれぞれのフォーム内で完結しているのであれば、メニュー画面側からは「呼び出せればそれでいい」という事になりますし、呼び出し側から何らかの制御が必要であっても、インターフェイスなりで規定しておけば良いと思いますし。 #「本当に画面が40も必要なのか?」というのはまた別の話ですけどね。 | ||||||||
|
投稿日時: 2005-02-17 21:04
ご本人から、質問に至るまでの経緯や仕様、その仕様とするに至る要件についての話しがほとんどありませんので、憶測で話を進めるのは難ありですが。。。 私はメニュー画面そのものを人数分作ろうとしているのだと思っていたのですが、その先の話し、ですか!! ん〜、なんか、何度か読み返して、混乱してきた。。。画面or機能遷移図が欲しいなぁ。なんか、もっとすっきり設計できるのに、とてもややこしく設計しているような気がする。。。 _________________ |
«前のページへ
1|2|3|4