- PR -

フォームの基本クラスについて

«前のページへ 1|2|3|4
投稿者投稿内容
cats
大ベテラン
会議室デビュー日: 2002/11/29
投稿数: 221
お住まい・勤務地: 東京
投稿日時: 2004-07-05 09:46
リフレクションを使っていて、VS.NETがおかしくなった点です。
・コンパイルができない。→理由：プロセスが残っていた。
・アプリAのみ、メニューが消えた。→理由：何故か、this.Menu=null;が追加されていた。
・アプリBのみ、bin、objが現れる。→理由：何故か、全てのファイルを表示にチェックが。
・ラベルが、表示されない。→理由：ラベル名が重複していたため？

とりあえず、全部直したものが次のものです。
http://plaza.harmonix.ne.jp/~fakira/turedure/TestSolution1.zip
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-07-05 10:34
引用:

リオッタさんの書き込み (2004-07-03 20:41) より:

１．タスクリスト（一番初めに起動される画面）：アプリA
　　・当画面が実質の親フォームとなります。

２．アプリB
　　・タスクリストのメニュから遷移します。
　　・遷移後、アプリBのメニューから他アプリに遷移します。
　　　→遷移する際、自分を消して次のアプリを起動させます。
　　・終了させるとタスクリスト（アプリA）に戻ります。
　　・自分への遷移はできないこととします。

３．アプリC〜アプリJ
　　・アプリBと同様の動作をします。

　ん？アプリＢ〜Ｊを、アプリケーションとして独立させる必要はあるのでしょうか？また、アプリＡから継承させる必要もありますか？
コード:
　　　　　　＜終了
　　　　　　　起動＞
タスクリスト＜−−＞アプリＢ−＞アプリＣ〜Ｊ
　　　　　　　｜−＞アプリＣ−＞アプリＢ、アプリＤ〜Ｊ
　　　　　　　｜−＞アプリＤ−＞アプリＢ，Ｃ、アプリＥ〜Ｊ
　　　　　　　・・・
　　　　　　　｜−＞アプリＪ−＞アプリＢ〜Ｉ

こうかな？アプリＢから他のアプリケーションではなく、ソリューション内の他のアプリケーションを起動する、でいいのかな？


　フォームそのものではなく、メニューだけ持ってくればいいのでは？
mover
常連さん
会議室デビュー日: 2004/06/20
投稿数: 47
投稿日時: 2004-07-05 18:08
皆さん

なんとかリフレクションにてメニュー機能を実現させることができました。
親切にしてくださってありがとうございます。
まだまだ勉強不足だと思い知らされています。

catsさん
C#のプロジェクトだったので、VB.NET用に作り変えました。
大変助かりました^^

Jittaさん
な、なんと、あのコメントにそんなからくりがあったんですね^^;
本当のコメントだと思ってました･･･。

それから、アプリAの親フォームと書いてあるのは、ベースフォームとは関係ないです。
紛らわしい書き方してしまいました･･･。
アプリA〜アプリJは全て、BASEフォームを継承しています。
そのBASEフォームにメニューを実装してます。

ZEBRAさん
なんとかXMLでチャレンジしてみます。
それで無理ならiniファイルにします^^;
mover
常連さん
会議室デビュー日: 2004/06/20
投稿数: 47
投稿日時: 2004-07-06 18:41
お世話になります。

catsさん

以下のように、FORM型にキャストしてしまうと、
test.Form1独自のpropertyにアクセスできなくなってしまいます。;;
何か良い解決策ないでしょうか？

propertyにせずコンストラクタでパラメタ渡しってのも有なのでしょうか？

'-------------------------------------------------------------------
Private Sub MenuItem3_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) _
Handles MenuItem3.Click

Dim mi As MenuItem = sender

Dim asm As [Assembly] = [Assembly].LoadFrom _
(String.Format("C:\test\bin\test.dll", mi.Text))
Dim sss As Type() = asm.GetTypes()
Dim obj As Object = asm.CreateInstance(String.Format("test.Form1", mi.Text))
Dim fm As Form = CType(asm.CreateInstance _
(String.Format("test.Form1", mi.Text)), Form)
fm.ShowDialog()

End Sub
'-------------------------------------------------------------------
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2004-07-06 19:12
引用:

リオッタさんの書き込み (2004-07-06 18:41) より:
以下のように、FORM型にキャストしてしまうと、
test.Form1独自のpropertyにアクセスできなくなってしまいます。;;
何か良い解決策ないでしょうか？

test.Form1って起動対象のアプリケーションのことですか？
だとすると、もともとの目的がこれへの参照を持たずに済ますことですから、言ってることが矛盾してますよね。

参照しない＝静的に型情報を取れないということです。静的に型情報が取れない＝実行できないではありませんが、どちらにしても元々コードはアプリケーションに依存できないはずですよね？

で、プロパティにアクセスして何をしようとしているんでしょうか？
もし共通の基底クラスのプロパティにアクセスしたいのであれば、基底フォームの型にキャストすればそのままアクセスできます。

ところで、コード中のString.Formatっていったい何をしてるんでしょうかσ?

[ メッセージ編集済み 編集者: なちゃ 編集日時 2004-07-06 19:13 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-07-06 19:50
to:リオッタさん
引用:

なちゃさんの書き込み (2004-07-06 19:12) より:

もし共通の基底クラスのプロパティにアクセスしたいのであれば、基底フォームの型にキャストすればそのままアクセスできます。

というか、その為の基底クラスです。共通して必要なものは、基底クラスに持たせます。

　または、プロパティをインタフェースで宣言することができますから、インタフェースを宣言して、子フォームに実装させます。基底クラスでは、インタフェースにキャストして使用します。


　やっぱり、設計図を描いて見直すのがよくないですか？単に「コーディングが面倒だから」継承を使う、というのであるなら、それは間違いです。動機の一つとなり得ますが、動機のすべてとなってはいけません。

　設計図は、UMLがわかるならUMLを。わからないなら、とにかく四角を描いて、その中に「やらなければならない作業」と、「保持しなければならないデータ」を書きます。とにかく全部のフォームでその四角を描いて、その上で共通するものがあるか探します。共通するものを「基底クラス」に抜き出します。また、「やらなければならない作業」については、「作業内容」としては同じだけれど、実際にやる手順が違うならインタフェースとして抜き出します。
mover
常連さん
会議室デビュー日: 2004/06/20
投稿数: 47
投稿日時: 2004-07-07 00:19
お世話になります。

Jittaさん
catsさん

すいません、ただ単に基底クラスでキャストしてやれば良いだけでした…。
色々と考えてると自分自身整理が付かなくなって、てんぱってました。

ひとまずココで、クラス図を描いて自分自身で整理していきたいと思います。
最後までアドバイスしていただき大変感謝しています。
«前のページへ 1|2|3|4

スキルアップ／キャリアアップ（JOB@IT）