C#, C♯, C＃相談室 Part59

1 名前：デフォルトの名無しさん [2010/05/16(日) 23:13:52 ] (#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。 前スレ  C#, C♯, C＃相談室 Part58 pc12.2ch.net/test/read.cgi/tech/1269261310/ Visual C# 2008 Express Edition 日本語版 www.microsoft.com/japan/msdn/vstudio/express/vcsharp/ その他テンプレ>>1-5くらい 654 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:15:29 ] >>618 なんか違わないか？ その例だと、スレッドBでdata1,data2が「正しく」読める保証は何もないのでは？ でなきゃ、そもそもvolatileって何だって話になる。 655 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:26:12 ] >>654 ＞でなきゃ、そもそもvolatileって何だって話になる。 どういう意味？？ 何言ってるのかわからない。 そりゃまあ>>618には実際にはいろいろ前提があるのは確かだが、 文脈で言いたい事柄の意図は通じると思うが。 656 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:29:24 ] >>654の指摘が何を言おうとしてるのかわからないので、そうだな、 ＞その例だと、スレッドBでdata1,data2が「正しく」読める保証は何もないのでは？ なぜ保証がないのかを具体的に書けばそちらの意図はわかるかもしれん。 657 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:33:09 ] 無意味な実装検証してもしょうがないような 658 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:35:39 ] >>656 そもそもその保証がない（コンパイラの最適化によって変数そのものには アクセスしない可能性がある）から、そういう可能性を排除するためのvolatileの はずなんだけど.... どうもこのスレ、分かってるのか分かってないのかよく分からん人が多いよな 659 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:38:32 ] volatileの使い方？を勘違いしてる 660 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:42:04 ] ひょっとして>>590の後半に書いてるような、よくある誤解をしてるクチかな？ 661 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:43:49 ] よくある誤解、ねえ.... 662 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:44:48 ] >>658 それがよくある誤解。そんなことは起こらない。 何度も何度も何度も出してるけど ttp://www.microsoft.com/japan/msdn/msdnmag/issues/05/10/MemoryModels/default.aspx でも読んでみ。 ※今はC#のvolatileの話だぜ 663 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:49:59 ] volatileの意味を誤読してるとか 664 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:51:18 ] >>658 メモリモデルの意味を全く理解してないな。 だったら、例えばもしlockで排他制御してた場合に、 他スレッドで更新した変数をlock内できちんと読めるのはなぜか考えてみな。 最適化で削除されるならそれすら保証されなくなる。 lock内では削除したらダメってコンパイラにはわかってるだろとか考えなしなこと言うなよ。 lock内から呼び出される普通のメソッドだってあるんだからな。 コンパイル時にそこがlock内かどうかなんて判断は無意味なこと。 665 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:53:01 ] >>662 だからvolatileの話じゃないし。 その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」 とは書いてないように思うが。 666 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 21:58:40 ] メモリモデルのルールをよく読め。 ------ 読み取りが、同一スレッドから同一ロケーションに対する別の読み取りに隣接している場合、その読み取りは削除のみ可能。 書き込みが、同一スレッドから同一ロケーションに対する別の書き込みに隣接している場合、その書き込みは削除のみ可能。 規則 5 により、複数の読み取りまたは書き込みを隣接させてから、本規則を適用することが可能です。 ------ 667 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 22:01:01 ] ＞その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」 ＞とは書いてないように思うが。 あのな、volatile読み取りより後の読み取りは必ずvolatile読み取りより後で実行されるってのは、 CPUのキャッシュ制御を含んだ話だよ。 >>618 ではvolatile読み取りの後に変数にアクセスしてるだろうが。 だから必ずキャッシュではなく（別スレッドで更新された）最新の値が読み取られる。 っていうかそのためのvolatileだって話。 668 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 22:02:41 ] どれとも ＞その参照先のどこにも「C#ではキャッシュを読む最適化は行われない」 ＞とは書いてないように思うが。 これはCPUキャッシュじゃなくて、レジスタにキャッシュするとか、そういう意味で書いてるのか？ それなら、それこそ>>666の話だ。 隣接する同一ロケーションからの読み取り以外で、読み取りが最適化によって削除されることはない。 669 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 22:10:40 ] >>666 「ケースAの場合、readのみが削除可能」という文章は、 「readが削除されるのはケースAの場合のみである」という意味ではない。 大丈夫？ >>667 どう読んでも君が思ってるような意味には解釈できないと思うが... 「処理Aと処理Bはシーケンシャルに実行されます」の意味は、 処理Aに続いて行われる処理Bに対して最適化が行われない、などということを意味しない。 670 名前：デフォルトの名無しさん mailto:sage [2010/06/18(金) 23:40:03 ] ふえ？ 671 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:00:00 ] ＞「ケースAの場合、readのみが削除可能」という文章は、 ＞「readが削除されるのはケースAの場合のみである」という意味ではない。 ＞大丈夫？ あほくさいこと言う前にそのページ全体をよく読んでみろよ。 メモリモデルをどのように定義してるか書いてあるから。 「メモリ モデルは、順次一貫性モデル (最も制限的かつ厳密なモデル) をベースとし、」ってとこらへんな。 だいたいそんなこと言ったら書いてないことだらけなんだから、そういう読み方じゃおかしいことくらいわかろうに。 ＞「処理Aと処理Bはシーケンシャルに実行されます」の意味は、 ＞処理Aに続いて行われる処理Bに対して最適化が行われない、などということを意味しない。 どこの記述のことを言ってるのかわからんがな、処理Bの最適かって具体的に何のことを言ってる？ 読み取りの最適化なら、前に読んだ値をキャッシュしておくくらいしかないだろ。 メモリモデルでは、そういうのを読み取りを前に移動するという風に定義してるんだよ、上のページにちゃんと書いてある。 そして読み取りはvolatile読み取りより前に移動できない、 つまり、volatile読み取りより前に読み取りをキャッシュしておくという最適化は許されない。 全部書いてある。 672 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:04:49 ] もういちいち説明するのめんどくさい、勝手に自分流解釈しとけ。 メモリモデルのこととかある程度わかってる人間ならすぐに理解できる話だ。 volatile絡みのルールの話も、マルチスレッドでのメモリモデルの一般的な話を理解してるなら はっきり言って常識レベルの話（ごくごく一般的なルール、javaのメモリモデルも同じようなルール）。 一回マルチスレッドのメモリモデルや順序について詳しく調べてみ。 673 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:17:33 ] >>658 お前が分かってないことははっきりしてる。 674 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:27:55 ] >>658 ＞そもそもその保証がない（コンパイラの最適化によって変数そのものには ＞アクセスしない可能性がある）から、そういう可能性を排除するためのvolatileの ＞はずなんだけど.... ttp://msdn.microsoft.com/ja-jp/library/aa691105.aspx Cとかの感覚で言ってるのかもしれないが、今どきのマルチスレッドを前提とした havaやC#のような言語では、そう簡単にアクセスそのものが消されることはないよ。 マルチスレッドで正常な動作を保証するために（保証するようなコーディングができるようにするために）、 メモリモデルというものを定義して、そのルール内で最適化を行うようになってる。 だからlockやvolatileなどをルールに従って使用して、正常に動作することが保証できるコーディングを行える。 675 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:36:38 ] Wordドキュメントになってるc#言語仕様の、10.5.3 Volatile フィールドの説明でも、 >>618のような動作を正常に行えるようにvolatileを使う例が書いてあるな。 まあ日本語がおかしくて意味不明な感じに読めてしまうけどな。 言ってることはまさに>>618と同じ。 676 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:38:40 ] using System; using System.Threading; class Test { public static int result; public static volatile bool finished; static void Thread2() { result = 143; finished = true; } static void Main() { finished = false; // Run Thread2() in a new thread new Thread(new ThreadStart(Thread2)).Start(); // Wait for Thread2 to signal that it has a result by setting // finished to true. for (;;) { if (finished) { Console.WriteLine("result = {0}", result); return; } } } } この例では、次のように出力されます。 result = 143 この例では、Main メソッドが Thread2 メソッドを実行する新しいスレッドを開始します。このメソッドは、値を result という非 volatile フィールドに格納し、 次に volatile フィールド finished に true を格納します。メイン スレッドは、フィールド finished が true に設定された時点で、フィールド result を読み込みます。 finished は volatile として宣言されているため、メイン スレッドはフィールド result から値 143 を読み込む必要があります。 フィールド finished が volatile として宣言されていない場合は、finished への格納後に result への格納がメイン スレッドから参照可能になります。 その結果、メイン スレッドがフィールド result から読み込む値は 0 になります。finished を volatile フィールドとして宣言すると、このような矛盾を回避できます。 677 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 00:46:04 ] あっそ 678 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 13:25:41 ] >>658 かたくなにそう信じてるやつがいるんだな… 元々意味のない参照ならそうなる場合はあるが、 普通ほとんどの場合は違うのに。 679 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 13:38:21 ] >>669 ｷﾘｯ ついていけないならくだらんケチつけなきゃいいのに 680 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 16:08:49 ] また同じヤツが暴れてるのかｗ お前はもうマルチスレッドとか無理だからあきらめろｗ 681 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 18:18:54 ] クラスアセンブリ(dll)を許可するプロジェクトだけに読み込ませるにはどうすればいいのん？ 682 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 18:31:32 ] >>681 コールしているアセンブリの署名を調べる。 683 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 18:41:02 ] >>682 ｋｗｓｋ！ ちなみにクラスアセンブリは自前のソース月の物でありまする＞＜ 684 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:09:18 ] 署名は改ざん検知出来るだけ DLLのアクセス制限云々の機能ではない 685 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:29:04 ] やっぱりそうなんですね がっくし・・・・ ProjectA ---{OK}--- A.dll 第三者のProject ---{NG}--- A.dll みたいな事をやりたい時はみんなどうしてるのん？ 686 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:32:12 ] そんなことをやりたいと思ったことがない。 687 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:35:14 ] えー社内ライブラリとかどう管理してるのー？ 不正リンクされて盗まれても「でへへっ！」とか言うだけ？ うそーん＞＜ 688 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:38:50 ] >>685 ＤＬＬのファイルかフォルダにNTFSのアクセス権つければよくね？ 689 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:47:26 ] 制限出来れば リフレクション使ってクラス調査→不正リンク→(ﾟ∀ﾟ )ｱﾋｬﾋｬ という.net固有の糞みたいな問題が解決するけど 未だに対策は難読化しかない。 690 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:53:51 ] 別になぁ。そもそもアセンブリじゃないDLLなら呼び放題だし。 売り物ならライセンス処理つけるだろうし。 お買い上げありがとうございました。だろ？ 691 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:55:50 ] オープンソース時代だから別にいいじゃんｗ 盗まれたら裁判すればいいし(ｷﾘｯ 692 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 19:58:48 ] >>691 盗んだほうはC++で書きましたってオチだ 693 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:08:44 ] .NETでなくても、製品の実行ファイルや図版を勝手に使われたらどうするんだよ。 そういうときは法務部門や顧問弁護士の出番。 694 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:18:14 ] まっ、やり放題な業種だからどうしようもないってこった 裁判なんざ普通は起こせないしそもそも把握すること事態が不可能 695 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:47:43 ] ヤリ放題な業種だと自分に言い聞かせてるのか？こっちまで巻き込むなよ。 696 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:50:51 ] 巻き込むも何も対策方法が何もない現状 自作パッカー作ったところで焼け石に水 理想は寝て言え 697 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 20:50:51 ] >>683 どのアセンブリからコールされているかはわかるだろ。 そして、そのアセンブリがどのような署名されているかを調べる。 逆コンパイル防止はそれ以前の問題。 698 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:05:35 ] 毎回、毎回、クラス毎に調べるのか？ 手間かかりすぎだろ 699 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:07:48 ] いたるところで StrongNameIdentityPermission でDemandでもしとけ。 まあ改ざんされたらもうだめだけどな。 700 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:45:18 ] 単純に public class MyLicence : License { public override void Dispose() {} public override string LicenseKey { get { return ""; } } } public class MyLicenceProvider : LicenseProvider { public override License GetLicense(LicenseContext context, Type type, object instance, bool allowExceptions) { if (allowExceptions) { string exename = Path.GetFileName(Assembly.GetEntryAssembly().Location); if (! exename.Equals("MyLicenceTest.exe")) { throw new LicenseException(type, instance, "do't licenced"); } } return new MyLicence(); } } [LicenseProvider(typeof(MyLicenceProvider))] public class TestClass { License license; public TestClass() { license = LicenseManager.Validate(typeof(TestClass), this); } } とかでもいいんじゃね？呼び出し元exe名縛り。 701 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:54:35 ] こんな抽象クラスあったのか。 中々面白いアプローチだと思う。 702 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 21:59:05 ] ほぉ、これはなかなか… 703 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:05:48 ] >>701-702 そりゃどうも。えっへん！ 704 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:06:08 ] Licenseは破棄が必要だぜ… 705 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:07:59 ] と思ったけど必要なければ別に実害はないのか… 706 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:10:53 ] リソース持ってないし、いいかな？と省略したけど、実装する際は通常通り Dispose()しといたほうがいいだろね。 707 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:14:16 ] リソースというか取得したライセンスを開放する処理を好きに定義するだけでしょ 同時利用数をデクリメントするとか 空でも全く問題ない 708 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:20:59 ] ってことみたいね。 709 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 22:48:04 ] というか、キモはexeのファイル名を確認するところなんだから、実装の仕方は人それぞれでしょう。 710 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 23:10:48 ] ってことみたいね。 711 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 23:30:09 ] >>700をoverrideとか使わずにもっと分かり易く書いてくれ 712 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 23:33:20 ] webアプリで FileSecurity filesecurity = File.GetAccessControl(path); (pathはstring型でファイルの絶対パスが代入されています） としました。 このファイルを他のアカウントで作成して、 アクセス権限も拒否にしたら、デバッグ環境でですが、 '/'アプリケーションサーバーエラーが発生しました。 と出て、実行できませんでした。 とりあえず、try catchを使い、アクセス禁止として 処理すれば、実行エラーは回避できました。 DACLとかいまいちわかっていないのですが、 なにか他の回避方法はあるでしょうか？ よろしくお願いします。 713 名前：デフォルトの名無しさん mailto:sage [2010/06/19(土) 23:33:38 ] そんなレベルだったら余計なこと気にするな どうせその他の部分で穴だらけ 714 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 00:00:25 ] >>711 public class Hoge { 　　private Hoge() {} 　　public static Hoge() 　　{ 　　　　string exename = Path.GetFileName(Assembly.GetEntryAssembly().Location); 　　　　if (exename != "hoge.exe") 　　　　　　throw new Exception(); 　　　　return new Hoge(); 　　} } でも、リフレクションやLCGを使われたらどうなるの？ 715 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 00:27:30 ] LicenseProviderって使ったことなかったからそのサンプルコードとしては 参考になったけど、正直実用的な意味があるとは思えんなあ… アセンブリがロードされた時に何らかのスタティックメソッドの実行を強制できれば いろいろ面白いことが出来そうな気がするんだけど 716 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 00:43:56 ] そうそう、今回の話とは別に、それ前からほしかったんだよね。 717 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 01:26:14 ] 実用的には例えばSIDとかMACとかUSBメディアのPNPDeviceIDとか ※ SID : GetComputerName、LookupAccountName API参照 ※ MAC : NetworkInterface.GetPhysicalAddress 参照 ※ PNPDeviceID : WMI で Win32_DiskDrive, Win32_DiskDriveToDiskPartition, Win32_LogicalDiskToPartition, Win32_LogicalDisk 参照 そういった利用者を一意に特定出来る情報をプロダクトキーと一緒に公開鍵で 暗号化してライセンス認証サーバに送って、サーバで認証後に秘密鍵で 特定情報を暗号化して送り返してもらったものを記録。 その情報を公開鍵で復号して動作環境での取得値と一致していなかったら ライセンス違反と判断・・・とかメンドクサい実装は必要に応じて。 718 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 01:53:37 ] うんまあ改ざんされたら意味ないんだけどね。 719 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 02:49:16 ] それを言ったらどんなアプリ、ExcelだろうとWindowsOSだろうと、リエンジニアリング されてライセンス処理部を改ざんされたら無理。 それを言うことに意味はあるのかな？ 720 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 03:02:30 ] 簡単さが違うって話。 721 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 05:35:33 ] 確かにDllMain的なのは欲しいよな。 722 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 11:42:56 ] static イニシャライザでチェックしちゃいかんの？ 723 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 11:47:55 ] staticコンストラクタはいつ呼ばれるかわからない 724 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 12:00:08 ] アセンブリに属性をつけておいて その属性にstaticコンストラクタを仕込んでおけば dllを読みこんだタイミングで実行されたりしないかなあ 725 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 12:00:32 ] ふーん 726 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 12:08:28 ] >>724 されない カスタム属性っていうのはあくまでメターデータのラッパークラスなので インスタンスが作られるのはその属性を参照しようとしたとき 727 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 12:26:53 ] お前ら釣り耐性低すぎだろ 728 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 12:32:24 ] >>726 (ﾟ∀ﾟ) 729 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 18:55:14 ] >>700みて何じゃこりゃとおもったけど>>714見たら恐ろしく単純ｗ 730 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 19:30:28 ] 何十個もクラスをライセンス管理しないなら >>714 で充分だね。 731 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 19:53:32 ] >>729 遅い 732 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 21:27:20 ] >>700でも充分簡単じゃねぇか。 あんなのすら分からなかったらそもそもコードかけねぇだろ。 733 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 21:46:45 ] >>732 インデントの差だろ 734 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 22:42:20 ] まあ確実に言えることは、>>700 程度のコードが複雑に見えるんじゃライセンス保護 なんて当分は無縁だということ。 735 名前：デフォルトの名無しさん mailto:sage [2010/06/20(日) 22:50:21 ] >>733 専ブラで>>700をポップアップさせて見ればいい 736 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 00:53:37 ] うほ 737 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 10:19:51 ] 先生！ thread.spinwaitとthread.sleepってどう違うんですかっ？ MSDN読んでも引数の違いぐらいしかわからないです！ 高度な技術を持ってる人、おすえて！ 738 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 10:31:49 ] 解説読めよ。 739 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 11:41:25 ] >>738 わかりません！ 740 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 18:04:49 ] Windowsフォームアプリを作るとメインウィンドウのクラスがめっちゃ大きくなっちゃうんですが、仕方ないんでしょうか？ それともpartialで分割するべきですか？（あまり意味ないと思いますが） 741 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 18:11:42 ] partialの分割は意味ない。 ユーザーコントロールにするとか、ビジネスロジックを別クラスにするとか、 そんな感じ。 742 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 18:49:35 ] ApplicationContext使って、MainFormにはインタフェースレベルのプログラムしか書かないとかかな。 743 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 20:37:11 ] それでもコントロールの量が多いとイベントメソッドだけでもめっちゃ多くなっちゃうんですよね。 そこそこ普通のフリーツールくらいの規模でもメインウィンドウのクラスだけで何千行にもなっちゃう。 744 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 20:40:43 ] だから、そーゆーのはユーザーコントロールにまとめるんだってば。 745 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 20:43:21 ] で、デザイナがバグって正常に表示されない、とw あれたぶん2010でも放置なんだろうな 746 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 21:11:27 ] >>743 >>745 へったくそだなぁ 747 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 21:12:31 ] ユーザーコントロールが正常に動かないのは作り方が悪い 748 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 21:29:20 ] >>746 具体的に教えてよ 749 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 22:12:54 ] なんでそんなでかくなるんだろ。 イベントが盛りだくさんなの？ 750 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 22:17:36 ] ボタンが百個あるので、イベントハンドラが百個なんでしょ。 751 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 22:28:16 ] ボタン１個にいくつのイベントがあると思ってんだ 752 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 23:05:11 ] はなし が かみあって ない 753 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 23:35:24 ] やっぱへったくそだな 754 名前：デフォルトの名無しさん mailto:sage [2010/06/21(月) 23:50:20 ] >>746-747 素人臭い意見だな。 そんなわけないでしょw 実際ある程度やってみれば俺の言ってる意味がわかるよ。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef