トップページ⇒tech
1001コメント310KB

ふらっとC#,C♯,C＃（初心者用） Part67

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/12/16(木) 18:23:33
このスレッドは
「どんなにくだらないC#プログラミングに関する発言でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からない場合など、勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。

なお、テンプレ2行目が読めない回答者は邪魔なので後述のC#相談室に移動して下さい。

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっとC#,C♯,C＃（初心者用） Part66
http://hibari.2ch.net/test/read.cgi/tech/1290854247/

■関連スレ
C#, C♯, C＃相談室 Part63
http://hibari.2ch.net/test/read.cgi/tech/1289733048/
VB.NET質問スレ(Part35)
http://hibari.2ch.net/test/read.cgi/tech/1284423653/
くだすれC++/CLI（初心者用）part2
http://pc12.2ch.net/test/read.cgi/tech/1268613679/

■備考
コードの量が多い場合は下記サイトを使うなどしたほうがいいかも
http://ideone.com/
コードを貼り付けてRun codeのチェックをはずしてsubmitボタンを押すと
コードを鯖側にアップして専用のアドレスが発行されます。

直接貼る場合は下記サイトなどを利用してhtmlエンコードした方が
インデントも残って見やすいです
http://kawama.jp/php/encode_html.php
0263デフォルトの名無しさん2010/12/26(日) 10:59:48
>>262
何かへんか? kwsk
0264デフォルトの名無しさん2010/12/26(日) 11:08:28
>>262
別に問題ないだろ
MSが提供するのは基本的なクラスであって必要とあれば継承して足せばいいだけ

実際Formアプリ作るときはFormクラスを継承したForm1とかにごりごりコード書くんだし
0265デフォルトの名無しさん2010/12/26(日) 11:30:21
>>263
推測を大いに含むが

class ExForm : Form
{

Model model;

ExForm(Model model){
this.model = model
}

void ok_ckick(object sender, EventArgs e){

model.HogeText = this.hogeBox.Text
DialogResult = DialogResult.OK
Close()
}

}

こういうことが言いたいんじゃないの
設計として正しいかは知らん
0266デフォルトの名無しさん2010/12/26(日) 11:35:53
余計な依存が増えてるだけじゃん
文字列渡すだけですむんだったら>>254の方が優れてる
0267デフォルトの名無しさん2010/12/26(日) 11:40:48
結果表示のためにダイアログを単発で表示するのはUI設計としておかしいってことじゃね
場合によるけど確かにウザいと思う
0268デフォルトの名無しさん2010/12/26(日) 11:41:30
Modelの結果をバリバリ使った高度なグラフ表示とかしたいなら
Modelを渡すようにした方がいいとは思うけど、簡単なメッセージだけなら
Form2はModelに依存させず文字列だけ受け取る方がいいと思う。
0269デフォルトの名無しさん2010/12/26(日) 11:45:59
あってるかどうかも分からない推測にマジ返し
これがプログラマの病んだ姿です
0270デフォルトの名無しさん2010/12/26(日) 12:31:44
たまに憶測で怒りだすやつがいるから困る。
そのくせ説明も聞かない。
怒りがおさまった頃に説明すると、「あ〜そう言うこと」って。。。
0271デフォルトの名無しさん2010/12/26(日) 13:12:14
溜まってるのね
0272デフォルトの名無しさん2010/12/26(日) 14:11:09
VBはまじ神だなぁどっかの糞#とは大違い
0273デフォルトの名無しさん2010/12/26(日) 14:17:00
F#の野郎・・・
0274デフォルトの名無しさん2010/12/26(日) 14:21:53
まあJ#はねえ
0275デフォルトの名無しさん2010/12/26(日) 14:29:59
故人のことを悪くいうなよ
0276デフォルトの名無しさん2010/12/26(日) 14:32:30
J#さんはアップデート版買う時にお世話になるんだから悪く言うなよ
0277デフォルトの名無しさん2010/12/26(日) 15:34:03
ｉｖとkeyを設定した後にメモリを覗かれたりするとやはりバレバレになっちゃうのでしょうか？

DESCryptoServiceProvider　des = new DESCryptoServiceProvider();
des.IV = ByteResize(iv);
des.Key = ByteResize(key);
0278デフォルトの名無しさん2010/12/26(日) 17:36:54
.net2.0です。ContextMenuStripをメインメニューの一部として使いながら
コンテキストメニューとしても使っているとメインメニューを表示するとき
勝手に閉じてしまうことがあるんですが、どうすればいいのでしょうか？
0279デフォルトの名無しさん2010/12/26(日) 18:00:27
>>277
うん
だから使い終わったら配列はゼロで埋める
パスワード用のStringはどうしようもないけどね
WPFではSecureStringで入力を受け取れるコントロールあるけど
0280デフォルトの名無しさん2010/12/26(日) 18:31:39
一つのGraphicsPathにAddStringで"□"を描いたのと、
Rectangleで箱の中に箱を描いた物を二つ並べて、
FillPath(Winding)で塗りつぶすとAddStringで描いた物だけ
中身が塗りつぶされないのはなんでなのん？
DrawPathで書いても見た目全く同じだし、パスポイント数も同じなのだけど。
違いが分からないれしゅ。
0281デフォルトの名無しさん2010/12/26(日) 18:55:50
うん
0282デフォルトの名無しさん2010/12/26(日) 19:03:44
>>280
コードくれ
0283デフォルトの名無しさん2010/12/26(日) 19:07:11
>>280
なんか考え方が80年代のMSベーシックのグラフィックだなw
たぶんなんでそんな風に考えるのか今の人には逆に理解できない気がする。
0284デフォルトの名無しさん2010/12/26(日) 19:09:28
>>283
WinFormも描画早すぎてあれだがベタな描画よ
WPFはしらんが
02852802010/12/26(日) 19:22:33
//using System.Drawing.Drawing2D;

Graphics g = pictureBox1.CreateGraphics();
GraphicsPath GP = new GraphicsPath();

GP.AddString("□", new FontFamily("MS UI Gothic"), (int)FontStyle.Regular, 100.0f, new Point(100, 0), new StringFormat());
GP.AddRectangle(new Rectangle(20, 20, 60, 60));
GP.AddRectangle(new Rectangle(10, 10, 80, 80));
GP.FillMode = FillMode.Winding;
g.FillPath(Brushes.Black, GP);
//g.DrawPath(Pens.Black, GP);

こんな感じ。
パスで自由に図形描けるようにしていて、
Windingモードでも塗りつぶされない図形は何が違うのか知りたかったのです
0286デフォルトの名無しさん2010/12/26(日) 19:35:12
>>285
わからん
http://ideone.com/Gl85f
0287デフォルトの名無しさん2010/12/26(日) 19:35:53
■なら塗りつぶされるだろうけど・・・
何がしたいんだ？
0288デフォルトの名無しさん2010/12/26(日) 19:38:30
FillMode.Windingでぐぐるとここへいけて
http://dobon.net/vb/dotnet/graphics/fillrectangel.html

塗りつぶしモードを指定する　ってところのリンクに
http://social.msdn.microsoft.com/Search/ja-jp/?Query=FillMode+%E5%88%97%E6%8C%99%E4%BD%93+System.Drawing.Drawing2D
0289デフォルトの名無しさん2010/12/26(日) 19:41:06
http://msdn.microsoft.com/ja-jp/library/system.drawing.drawing2d.fillmode%28VS.80%29.aspx
>Winding モードでは、交差部分ごとにパス セグメントの向きを考慮します。
>時計回りで交差部分ごとに 1 を加算し、反時計回りで交差部分ごとに 1 を減算します。
>結果が 0 でない場合、その点は塗りつぶし領域またはクリップ領域の内側と見なされます。
>0 の場合、その点は塗りつぶし領域またはクリップ領域の外側にあります。
>図形が時計回りか反時計回りかは、その図形のセグメントの描画順序で決まります。

ということだそうだ
0290デフォルトの名無しさん2010/12/26(日) 19:46:01
そんな難しいこと言わなくても、「文字は閉曲線ではない」ってだけの単純な話だから。
こんなん当たり前じゃん。
アホかといいたくなる。
0291デフォルトの名無しさん2010/12/26(日) 19:56:21
GP.AddRectangle(new Rectangle(20, 20, 60, 60));
GP.Reverse();
GP.AddRectangle(new Rectangle(10, 10, 80, 80));
これで口とおなじになる
0292デフォルトの名無しさん2010/12/26(日) 20:00:29
ロの中身て■にならないってことか
確かTrueTypeフォントってPathの塊じゃなかったっけ？
0293デフォルトの名無しさん2010/12/26(日) 20:06:08
TrueTypeフォントはこんな感じでPathで閉じた形になってるので
ロのようなのは中が塗りつぶされない
そもそも単純なRectangleを重ねたのとは違う
http://www.geocities.jp/y_hobby_2/blogimage/truetypefonteditor.png
02942802010/12/26(日) 20:10:38
パスの特性ちゃんと理解してなかったです
>>289で謎が解けました
ありがとう！！
>>291確かにそれでもいけますね

パスをとじた形の、閉じ方が分かっていなかったのです。
解決しました、ありがとうございました！
0295デフォルトの名無しさん2010/12/26(日) 20:30:42
好みのような気もしますが質問です。
イベントを定期的に発生させるクラスAがあって
Aを複数管理しているクラスMGRがあります。
※Aは管理クラスMGRのインナークラスで、MGRのメソッド内部でインスタンスが作られる

Aのイベント発生を管理クラスMGRも別のクラスXでも受け取りたい場合
AのイベントにMGRもXもイベントハンドラーを登録できるようにした方がいいのか
MGRにもAと同じイベントを作って、Aイベントに登録はMGR、MGRのイベントに登録はXとして
Aイベント発生→BイベントハンドラーでBイベント発生→Xの流れにした方がいいのか
どちらの方が良いと思いますか？？
0296デフォルトの名無しさん2010/12/26(日) 20:32:09
あ、最後のあたり間違ってる；

＞Aイベント発生→BイベントハンドラーでBイベント発生→Xの流れにした方がいいのか
Aイベント発生→MGRイベントハンドラーでMGRイベント発生→Xの流れにした方がいいのか

です・・・。
0297デフォルトの名無しさん2010/12/26(日) 20:34:26
インナークラスと外側のクラスの間の通知にイベント使うのは無意味
AにMGRのインスタンスを渡してAの中から通知用のMGRのprivateメソッドを呼ぶだけでいい
Xについては、MGRがXの存在を知っているんだったらイベント使わなくても単にMGRがXのメソッドを呼ぶ
MGRとXを切り離したいならMGRのイベントにXのイベントハンドラを登録する
02982952010/12/26(日) 20:51:16
>>297
なるほど！
ありがとうございます〜。
0299デフォルトの名無しさん2010/12/26(日) 20:52:31
イベントって、
・クラスaがクラスbに依存してる(aの中でbを明示的に使ってるという意味)
・bはaに依存させたくない
・bの状態変更をaに通知したい
ときに使うものなんだよね
そういうケースってそれほど多くない
bがaに依存していいなら、イベントなんて使わずに普通にbがaのメソッドを呼べばいい
0300デフォルトの名無しさん2010/12/26(日) 21:04:34
>>299
基本依存ないけど、
＞そういうケースってそれほど多くない

これは言いすぎだと思う。
分野によってはイベント多用するよ。
0301デフォルトの名無しさん2010/12/26(日) 21:39:07
相互に参照を持ち合ってるってのはなんか気持ち悪い
0302デフォルトの名無しさん2010/12/26(日) 21:48:15
イベントってほぼ例外なく暗に相互に参照持ってるんだけど
0303デフォルトの名無しさん2010/12/26(日) 21:54:46
参照がないとメソッド呼べないし
0304デフォルトの名無しさん2010/12/26(日) 22:13:39
オブジェクトの参照握ってるってのと、
アセンブリとかクラスを参照してるってのは別の話。

イベント使ってる時点でオブジェクトは参照されるけども、
アセンブリやクラスの参照は切れる。
これが大事。
0305デフォルトの名無しさん2010/12/26(日) 22:48:22
また適当なこと言う子が来たなw
0306デフォルトの名無しさん2010/12/26(日) 23:03:13
クラスを参照ってなんだ?
Type t = typeof(Unko)　のことか?
0307デフォルトの名無しさん2010/12/26(日) 23:24:17
変数の宣言で内容を自動で暗号化するものがあったと思うのですが、
どういう書き方をしたら良かったでしょうか？
0308デフォルトの名無しさん2010/12/26(日) 23:27:37
C# 4.0 specificationには見当たらないな。
0309デフォルトの名無しさん2010/12/26(日) 23:33:34
相互依存が多用されてたらユニットテストが糞めんどくさい。
慣れてくると自然に余計な依存を持たないような設計するようになる。
個人だったり小規模だったりするなら好きにやればいい。
0310デフォルトの名無しさん2010/12/26(日) 23:42:46
>>306
csc.exe /r:Xxx.dll とか、VS上での「参照の追加」の参照。

>>307
SecureString のこと？
宣言というか、型だけど。
0311デフォルトの名無しさん2010/12/26(日) 23:44:50
>>310
それです！
昔、ＨＰで見た覚えがあったのですが書き方がわからなかったのです

ありがとうございます
03123062010/12/26(日) 23:46:56
>>310
csc /rはコンパイル時の話だろ。「参照が切れる」ってなんだよ?
0313デフォルトの名無しさん2010/12/27(月) 00:09:23
参照設定を行わなくてもコンパイルできる(参照を切ることができる)
という意味ではないでしょうか
0314デフォルトの名無しさん2010/12/27(月) 00:28:54
>>312
あんたにはUnkoというコテハンを使う権利をやろう
0315デフォルトの名無しさん2010/12/27(月) 00:42:04
参照設定が必要な相手と相互に依存することなんてあるの？
0316デフォルトの名無しさん2010/12/27(月) 00:44:25
双方向依存なくさないとアセンブリ分割できないね。
それも含めて「参照を切る」でしょ。
0317デフォルトの名無しさん2010/12/27(月) 00:47:38
いや・・・そう言う場合、普通はインターフェースを使うかと
0318デフォルトの名無しさん2010/12/27(月) 00:52:57
イベントでできること、もちろんインターフェイスでできるよ。
（今はなしてるのは、なんでイベントなんて使うかって話よね？＜参照切り）

Java が断固デリゲートを入れようとしなかったのも、インターフェイス至上主義だからだし。
そんな Java も最近、デリゲート入れようとしてるわけで、やっぱ欲しいのよ、デリゲート。

要は、
・インターフェイスだとマルチキャストがめんどくさい
・AddListner/RemoveListenr 書くの面倒
　　→ setter/getter の代わりにプロパティ作ったのと一緒で、イベント作った
0319デフォルトの名無しさん2010/12/27(月) 01:03:06
>>304あたりから参照の意味が変わってるなw
もう自分が語りたい事を勝手に語ればいいんじゃね
0320デフォルトの名無しさん2010/12/27(月) 01:05:52
>>315
DLLの粒度によるんだと思うよ。
DB関連のDLLとログ出力のDLLで、
DBの方はエラーログ出力とかしてて、
ログ出力先がDBだったら相互参照になるよね。
1DLLに収めちゃえば問題ないのに。
>>317の言う通りだと思うけどめんどくさい
0321デフォルトの名無しさん2010/12/27(月) 01:14:00
何の話をしているよかよく分からんけどw
とりあえず、少なくともVS使う限りではプロジェクトの循環参照はできないから、
そこは>>315-316が正しいんじゃないの？

どうも「依存関係の逆転の原則」とか言うときの依存って言葉と参照って言葉を混同した人がいたのが
話の始まりなのかなという印象。
0322デフォルトの名無しさん2010/12/27(月) 01:32:18
301だが
class A {
  B b;
...
class B {
  A a;
...
っていうのが嫌だと言いたかった。それだけなんだ
0323デフォルトの名無しさん2010/12/27(月) 01:39:31
大丈夫、おれは分かってたよｗｗｗ
302からおかしくなったんだよな
0324デフォルトの名無しさん2010/12/27(月) 01:40:59
わかったようなこと言うなよ。
俺は何もかわっちゃいねえよ。
0325デフォルトの名無しさん2010/12/27(月) 01:43:37
何も変わらず何もわかってないｗ
0326デフォルトの名無しさん2010/12/27(月) 01:47:46
結論：イカ娘可愛い
0327デフォルトの名無しさん2010/12/27(月) 02:42:05
>>322みたいになりそうだったらどうすればいいの(´・ω・｀)？
0328デフォルトの名無しさん2010/12/27(月) 02:57:08
つイカーフェイス
0329デフォルトの名無しさん2010/12/27(月) 03:08:09
interface IB {}
class A { IB b; }
↑
依存
｜
class B : IB {}

とか、

delegate void BEventHandler(object sender, BArg arg);
class A { event BEventHandler handler; }
↑
依存
｜
class B { void SomeMethod(object sender, BArg arg }

とか。
0330デフォルトの名無しさん2010/12/27(月) 03:11:11
さらに言うと、IBとかBEventHandlerの代わりに、
標準ライブラリに入ってるインターフェイス/デリゲートを使えば、
直接的な依存は完全に切れる。

あと残りの課題は
A a; a.b = new B();
とか
a.handler += new B().SomeMethod;
とかを誰がやるか。

この辺り解消するのが WPF のデータバインディングとか、MEF。
0331デフォルトの名無しさん2010/12/27(月) 03:20:42
イベントにしたりデリゲートで渡したりインターフェース使ってみたり、いっそ1つのクラスにしちゃったりpartialだったり
アセンブリ単位では循環参照してもいい。でもアセンブリ単位境界を越えて循環参照するのは設計ミスなので禁じられている。
0332デフォルトの名無しさん2010/12/27(月) 03:24:36
イカに一票
デリゲートはメソッドを抽象化したい時に使え
0333デフォルトの名無しさん2010/12/27(月) 03:30:46
>>329-330
それだとBがAのメソッド呼んでた部分がなくなっちゃうよ
>>328から
interface IA {}
class A : IA { B b = new B(this); }
class B {IA a;}
こんな感じのを想像したんだけど
そもそも依存しあう設計が間違ってるってこと？
0334デフォルトの名無しさん2010/12/27(月) 03:32:42
>>333
A側にメッセージ返すインターフェイスなりイベントもA側のアセンブリに書けばOK。
アセンブリの循環参照は避けれる。

あとは、双方向バインディングとかの出番。
0335デフォルトの名無しさん2010/12/27(月) 03:49:01
>>334
よく解らんが(´・ω・｀)
例えばBがTCP通信しててデータ受け取ったよ的な通知とか
BがFormでボタン押されたよ的な通知とかはIBにイベント持たせればいいってことかね
0336デフォルトの名無しさん2010/12/27(月) 03:52:52
>>335
TCP通信ならイベントね。

Form なら、WPF のコマンドのバインディングがいいと思う。
0337デフォルトの名無しさん2010/12/27(月) 03:57:48
イベントならイカじゃなくて、デリゲート持てばいいよ
相互に依存って言ってたからお互いの複数のメソッドを利用しているように見えちゃった
0338デフォルトの名無しさん2010/12/27(月) 04:14:36
>Form なら、WPF のコマンドのバインディングがいいと思う。
WPFじゃない場合はIAみたいなのを作るってこと？

>相互に依存って言ってたからお互いの複数のメソッドを利用しているように見えちゃった
そのつもりですた
0339デフォルトの名無しさん2010/12/27(月) 08:04:47
非常にざっくりした質問で申し訳ないのですが・・・
自作のアプリが、他の市販のアプリと同時に使うと、
市販のアプリを誤動作させてしまうようです。
まだ自分は初心者で、自分のやりたいことを調べてやってるだけで、
安全対策も何もしてないので、原因はこっちにあるのでしょう。
こういう場合、原因の突き止め方とか、他に影響を与えない安全対策とか
参考になるサイトとかあれば教えてください。
0340デフォルトの名無しさん2010/12/27(月) 08:09:53
糞#ってｗｗ
選ぶのは言語使ってるができないのもあるｗｗ
まじワロタ、ｗｗｗひ
0341デフォルトの名無しさん2010/12/27(月) 08:29:51
>>340
大丈夫か？なんかへんだぞ
0342デフォルトの名無しさん2010/12/27(月) 10:24:28
>>339
何か特別な変なことをやっているんだろう。
一般的な対策とか原因なんかない。何も考えずに作っても普通はそんなことありえないんだから。
0343デフォルトの名無しさん2010/12/27(月) 10:29:34
WPFもやろうかなと思っているのですがおすすめですか？？
習得が大変そうな感じがするので迷っています。

フォームでも結構満足していますがさらに
便利になったりするのでしょうか？（難しいのが楽に作れたり）
0344デフォルトの名無しさん2010/12/27(月) 10:42:05
別に難しくはないけどね

結局は慣れだよ
0345デフォルトの名無しさん2010/12/27(月) 10:43:14
WinFormsと同じ感覚で使う分にはWPFも使い方はほとんど変わらん。ぜんぜん難しくない。
WPFは外観の自由度が高い。コントロールの見た目を変えようとして
WinFormsで大量のコードを書いた経験があるなら、そういうことはWPFの方が圧倒的に楽。
それとデータバインディングが強力。コントロールとデータの紐付けは全部バインディングで作れる。
WPF特有の部分は必要に応じて追々覚えていけば大したことない。
0346デフォルトの名無しさん2010/12/27(月) 10:47:26
むしろそのバインド処理を今までのWinFormsで使ってなかったから戸惑う・・・
確かにデザインはすごく楽
モッサリさえなくなればいいんだが・・・
0347デフォルトの名無しさん2010/12/27(月) 11:03:59
？
0348デフォルトの名無しさん2010/12/27(月) 11:05:58
public class test
{
public string text = null;
}
test d = new test();
d.test = "test";
d = null;

こういう書き方でnullを入れる人をみた事があるけど、この場合のd.textはnullを入れた
時点で消滅するのかな？。

それとも
d.test = null;
d = null;
にしないとd.test の内容はすぐに消えない？
l
0349デフォルトの名無しさん2010/12/27(月) 11:07:26
どっちにしろGCが走るまで消えない
だからってGC.Collect入れると余計に遅くなるよ
気にしても無駄
0350デフォルトの名無しさん2010/12/27(月) 11:08:30
>>348
アクセスしてみればいいｗ
0351デフォルトの名無しさん2010/12/27(月) 11:09:56
よっぽど実行時間の長いスコープでない限りローカル変数へのnull代入は無意味
気にしない・放置が基本
0352デフォルトの名無しさん2010/12/27(月) 11:12:28
>>348
http://ideone.com/DHPdZ
03533482010/12/27(月) 11:15:36
みんな、ありがと
メモリ上からd=nullだけで全部消えるのかと少し期待したのですが残念
0354デフォルトの名無しさん2010/12/27(月) 11:19:49
>>353
あくまで参照を切り離しただけでGCはまだ持ってる可能性はあるよ
ただ、参照を切り離したので>>352を実行するとエラーになる
0355デフォルトの名無しさん2010/12/27(月) 11:23:27
>>348のケースに限って言えばGCが走ろうと"test"は永遠に消えないけどな
リテラルはCLRが参照保持してるので絶対に消えない
0356デフォルトの名無しさん2010/12/27(月) 13:26:27
C# で質問です。XMLでシリアライズする時に既にインスタンス化されたクラスはできないのでしょうか？
0357デフォルトの名無しさん2010/12/27(月) 13:28:34
>>356
できるでしょ
でもシリアライズ用のクラスってpublicでいろいろ開放してないと使えなかったような
0358デフォルトの名無しさん2010/12/27(月) 13:36:08
規定のコンストラクタがあって
かつ
読み書きのできるパブリックフィールドとプロパティだけだったと思うんだけど

嘘だったらごめん
0359デフォルトの名無しさん2010/12/27(月) 13:41:58
>>356
俺はインスタンス化しないとシリアライズできないと思ってるけど。

インスタンス化されたクラス？がよくわからん。
0360デフォルトの名無しさん2010/12/27(月) 13:51:25
したいこととしては
あるクラスをシリアライズする場合に、プロパティにインターフェイスを継承している
項目をシリアライズしたいのです。
（Ex)
public class TextClass
{
public stirng Ex1 { get; set }

public int Ex2 { get; set; }

public IInterface { get; set; }

}

のようなクラスをシリアライズしたいのです。。
0361デフォルトの名無しさん2010/12/27(月) 13:52:36
追伸：
public IInterfaceがとあるインターフェイスを継承したものを格納しています
0362デフォルトの名無しさん2010/12/27(月) 13:54:41
>>344 >>345 >>346
ありがとうございます。
複雑な外観・バインディング（データの同期？）
などをしたい時にWPFを勉強しようと思います
■ このスレッドは過去ログ倉庫に格納されています