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

C#, C♯, C＃相談室 P ..

654:デフォルトの名無しさん
09/08/05 23:32:29
大漁ですな(；´Д｀)

655:デフォルトの名無しさん
09/08/05 23:34:36
式は右辺からと思っていると、
(a = b == c) == (a == b == c)
-> X == Y
の右辺Yからやることになり、地獄行きになるんです

656:デフォルトの名無しさん
09/08/06 00:13:44
(==)((a = b == c), (a == b == c))

657:651
09/08/06 03:03:09
>>652
すまん4行目は F == ((F == F) == T) だな。
結果は一緒。
URLﾘﾝｸ(msdn.microsoft.com)(VS.71).aspx

658:633
09/08/06 09:04:57
>>634-637
遅くなってすみません。

たとえば、スレッドAとスレッドBで変数myClassを共有している

スレッドAでは、myClassに新規インスタンスをセットする

while( 1 )
{
myClass = new MyClass();
}

スレッドBでは、myClassを作業用変数に確保し、さまざまな処理を実行する
while( 1 )
{
MyClass work = myClass;
workに対しての様々な処理
}

代入演算子はオーバーロードしていません
ちょっと何をやりたいかわかりにくいかもしれませんが、これだけを見た場合に問題はありそうですか？

内部的に参照カウント関係の処理が走っていたりして、危険だったりしますか？お願いします。

659:デフォルトの名無しさん
09/08/06 09:10:07
ダメダメ絶対ダメ
スレッドBのループが一回回る間にスレッドAのループが何回回るか全く分からないんだよ?
それにいくらメモリを意識しなくていいといったってさすがにノーウェイトでnewしまくったらGCの負担になる

660:デフォルトの名無しさん
09/08/06 09:21:04
スレッドAとスレッドBの周回数は同期がとれていなくていいです
GCの負荷は考慮しないとして、スレッドセーフかっていう質問なんですが・・・

要するに
myClass = new MyClass();
と
MyClass work = myClass;
のところをロックしないとメモリを壊したりしますか？ってことが聞きたいんです

C言語なら問題無いはずですがC#だとどうなのかな？って

>>635 の言うようにこれ自体はロックしなくても問題ないんですかね＾＾；

661:デフォルトの名無しさん
09/08/06 09:28:22
ｍｙClassが共有されてると言うことでおけー？
ロックされる云々の前に多分それ意図してるように動かないよ。エスパーしてみるとｗ

662:デフォルトの名無しさん
09/08/06 09:29:44
必ずしも間違った扱いではないけど問題あるかどうかは別だな
AでMyClassのコンストラクタが呼ばれた後に，Bで古いインスタンスが使われる可能性はある

663:デフォルトの名無しさん
09/08/06 09:32:02
ロックするならスレッドBの書かれてない処理のところじゃね？

664:デフォルトの名無しさん
09/08/06 09:36:37
参照やintへのアクセスはアトミックと規定されている。
つまり、myClassが32bitだとすると16bitだけ新しい値に書き換わってるという状態は存在しない。
一方doubleやlongはそういう状態が発生しえる。

ただしマルチCPUの場合はもう少しややこしくて、
スレッドAが書き換えたmyClassの内容がスレッドBに反映するまでにタイムラグが発生する場合がある。
これが問題になるならlockを使用するかmyClassをvolatileで宣言する。
Cのvolatileとの違いに注意。

665:デフォルトの名無しさん
09/08/06 09:44:52
あと、C#のGCは参照カウントじゃないよ。

666:デフォルトの名無しさん
09/08/06 09:58:55
ま、確実性という意味なら、volatileつけとけば確実。
ただしなくてもメモリが壊れるとかのレベルの問題はない。

実質的にはCLR2.0以降のメモリモデルと86系CPUのメモリモデルから、
事実上はvolatileなくても問題ないはず。

667:デフォルトの名無しさん
09/08/06 10:02:26
あ、確実というのは、可能な限り最新のインスタンスを使うという意味でね。

668:デフォルトの名無しさん
09/08/06 10:13:30
Interlocked.Exchangeでも使えば

669:デフォルトの名無しさん
09/08/06 10:40:47
volatileを使わない場合はもうひとつ問題があって、
MyClassの初期化が終わる前にスレッドBに参照が渡ってしまう可能性がある。
ただし、これが起きるのはMSだとItatiumの場合だけ。
原理的には有名なダブルチェックロッキング問題と同じ。

myClassをvolatileにしない場合のスレッドA
while(　true　){　
　MyClass　tmp　=　new　MyClass();
　Thread.MemoryBarrier();
　myClass　=　tmp;
}　

670:デフォルトの名無しさん
09/08/06 11:15:28
おまいら詳しいのな

671:デフォルトの名無しさん
09/08/06 11:20:35
それもCLR2.0以降では大丈夫でそ。
ついでにその問題を出すなら、Aのメモリバリアだけじゃだめ。

なぜなら、Bスレッドのワーク変数が目的通りに動かないから。
ワーク変数への各アクセスで、新しい参照を読んでしまう危険がある。
かなり直感に反する動作だと思うけど。

結局この場合もvolatileつけるのが最も簡単確実。

672:デフォルトの名無しさん
09/08/06 11:58:19
>>671
いや大丈夫でないから.NET2.0で.MemoryBarrier()が追加になってるわけで。

myClassからworkの参照コピーは１回限りのようだから問題ない。
work変数はローカルなんだし、
MyClassはスレッドAでセットしたあとは放置状態なのだから、
途中で新しい参照を読み込むことはありえない。
workは一貫したクラスを参照できてれば、MyClassのバージョンは問わないという前提だよ。

673:デフォルトの名無しさん
09/08/06 12:00:37
Ｃ＃　2.0で質問です。

List<int> _list = new List<int>();

//(本当はintではなくクラスなんですが説明しやすいようにintで・・・)

_list.Add(1);
_list.Add(2);
_list.Add(3);
_list.Add(4);
_list.Add(5);

foreach(int data in _list)
{
　Console.WriteLine(data);
}

このような感じで記述した時に
List<int>はインデックス0からデータを順番に必ず返すのでしょうか？
やってみた感じ必ず返っては来ているようなんですが、保障されているというような感じの文章がヘルプから探せなかったので質問させていただきました。
よろしくお願いいたします。

コレクションやソーテッドリストなんかはその並び順は勝手に変わるようですがListオブジェクトはどうもみあたらない・・・orz

674:デフォルトの名無しさん
09/08/06 12:11:22
foreach が配列の要素を走査する順序は、次のように定義されます。
1 次元配列の場合、要素はインデックス 0 から始まってインデックス Length ? 1 で終わるインデックスの昇順に走査されます。
多次元配列の場合、要素は、最初に右端の次元のインデックスが増加し、次にその左側の次元のインデックスが増加し、さらにその左側の次元のインデックスが増加する、というように走査されます。

675:デフォルトの名無しさん
09/08/06 12:37:54
>>674
int のコレクションとして考えれば0～インデックスの最後までの順序で処理される
それでもってListコレクションの中身も同じように処理されるということでしょうか？

ということであればすっきり処理を続けることができます。
ありがとうございました！

676:デフォルトの名無しさん
09/08/06 13:09:05
>>672
違うよ。
メモリバリアはCLIの標準仕様では必要。
CLR2.0以降の実装では不要だとしても、互換性の為には必要になる。
だからある。

あとソースコード上はワーク変数に1回だけ取得してても、
実際にはワーク変数を削除して毎回実体にアクセスするという、
直感的でない最適化が行われる可能性があるんだよ。

共有してる変数をvolatileにすればそれを防げる。

677:デフォルトの名無しさん
09/08/06 13:11:03
この辺はいつだったかのMSDNマガジンに詳しく書かれてる。

678:デフォルトの名無しさん
09/08/06 14:05:33
>>676
ありがと、勉強になった。MSDNマガジンで確かに見た気がするがスルーしてた。

679:デフォルトの名無しさん
09/08/06 14:46:29
ごめんもう一つ補足。
CLR2.0以降では書き込みアクセスでのvolatileは事実上不要だけど、
読み取りでは必要な可能性もあったと思う。
書き込み順序と回数はデフォルトでvolatileのように保証されるが、
読み込みは場合によっては省略されることがある。
ただ、その他諸々の事情により、実際に問題が出るパターンはあまりなかったと思う。

680:デフォルトの名無しさん
09/08/06 17:20:59
C#からUnmanaged-DLLを利用する場合についての質問です。

DLL側でThread Local Strage(__declspec(thread)を付けた静的変数)を使用し
ている場合、(DLL内の関数がC#から呼び出され)DLL内でこれにアクセスしよう
とした時にSystem.AccessViolationExceptionになるようです。(エラー画面.PNG)
DLL側を修正せずに、C#側の修正もしくは他の手段でこれを回避する方法はあ
りませんでしょうか？

URLﾘﾝｸ(www1.axfc.net)
は問題を再現する簡単なコード例です。
Test\MyDll\MyDll.cpp の18行目が__declspec(thread)を付けた静的変数で、
これを、N:\Test\MyCSApp\Program.cs の29行目から呼び出されたMyFunc(5)の
処理でszMyLastErrorにエラー情報をセットするところで例外が発生します。

Test\MyC++App は同じ処理をC++で記述した場合で、これは問題なく動作しま
す。

以上、よろしくお願いいたします。

681:デフォルトの名無しさん
09/08/06 17:43:07
>>680
URLﾘﾝｸ(msdn.microsoft.com)(VS.80).aspx
の一番下

682:デフォルトの名無しさん
09/08/06 17:57:52
C++/CLIあたりでlibを使ってラッパ作れば何とかなるかもね

683:デフォルトの名無しさん
09/08/06 21:44:03
レスありがとうございます。

>>681
症状からして、そのページに書かれていることが起きている(C#はDLLを動的にローディングしている)
のだろうな、とは思っていたのですが、それを回避する方法がなにかあるのではないかと質問させてい
ただきました。

>>682
MangedなラッパDLLを作成し、これにMyDll.libをリンクしてみましたが、ラッパDLLがC#アプリからは
動的にローディングためか結局ダメでした。

何か、裏技がありませんかねえ？？

684:デフォルトの名無しさん
09/08/06 21:52:25
別 Exe にしてプロセス間通信するしかないだろ。

685:デフォルトの名無しさん
09/08/06 21:57:02
C++/CLIから起動してC#側を動的ロードするとか

686:デフォルトの名無しさん
09/08/06 22:23:54
DLLのほうを触っていいならTlsAllocを使えばいいはずだけど。

687:デフォルトの名無しさん
09/08/06 23:40:08
COMのアウトプロセスサーバーでラップすると何とかなりそうだが、
激しくめんどい。
インプロセスサーバーだと駄目だった。

688:デフォルトの名無しさん
09/08/07 02:56:45
一番現実的なのは>>685だろうな
マネージ側は参照だけでいいんで動的ロードとか言わんけど

689:デフォルトの名無しさん
09/08/07 08:47:30
.NETのWindowsアプリケーションで作成したプログラムにおいて、
ネットワークPCのドライブにあるフォルダをアクセスしようとした時、
たまたまそのPCが立ち上がっていなくてネットワーク上に見つからない
場合に長く待たされていました。このタイムアウト時間はたぶんＯＳ
の設定で変えられるものとは思うのですが、タイムアウトにならない
うちにプログラムでアクセスを中断してしまうことは可能でしょうか？

690:デフォルトの名無しさん
09/08/07 10:09:55
C#でパケットキャプチャしたいのですが、サンプルありますか？

691:デフォルトの名無しさん
09/08/07 10:18:07
URLﾘﾝｸ(www.stackasterisk.jp)
URLﾘﾝｸ(sourceforge.net)

692:デフォルトの名無しさん
09/08/07 11:42:39
>>691
ども、でもなんかよくわからないです
エラー 2 型または名前空間名 'NetDefineSet' は名前空間 'StackAsterisk' に存在しません。アセンブリ参照が不足しています。
とか

693:デフォルトの名無しさん
09/08/07 12:04:49
お前にはまだ早いということだね

694:デフォルトの名無しさん
09/08/07 12:16:19
>>689
別スレッドでチェックしに行って適当にタイムアウトとかできるんじゃ？

695:デフォルトの名無しさん
09/08/07 13:22:57
>>692
そういやなんかサンプルそのままじゃビルドできなかった記憶があるな

>The Code Projectによいサンプルがあったので拝借させていただき、それを元に書いてみました。
>元となったのは「RawSocket Class-Create Network Monitoring (Packet Sniffing) Apps」というものです。

って書いてあるしそっちも参考にするといい

696:デフォルトの名無しさん
09/08/07 14:39:34
スレッド分けるのに一票

697:デフォルトの名無しさん
09/08/07 14:49:45
Process.Start()で存在しないフォルダを起動したら、FileNotFoundExceptionじゃなくてSystem.ComponentModel.Win32Exceptionというのが来る
Frameworkが吸収するところじゃないのか

698:デフォルトの名無しさん
09/08/07 15:34:45
あなたはそれがいいと思うかもしれないが、
大多数の他人はそう思わない

699:デフォルトの名無しさん
09/08/07 16:48:15
いやそうでもない

700:デフォルトの名無しさん
09/08/07 16:59:52
Frameworkが吸収すべき所のような気がするけど
実害は無いからとやかく言わない

701:デフォルトの名無しさん
09/08/07 17:06:23
>>697
つうかふつうに固まるだろ・・・・
問題はみに行く時に固まるつうのが問題なわけで

なにかボタン押したときにチェック
↓
チェック中ですのダイアログ的なものと共に強制キャンセルボタン
↓
チェック開始（バックグラウンドワーカーでもなんでも）
↓
バックグラウンド終了前にキャンセルされたら
ナックグラウンドワーカー停止

こんなんでいいんじゃね？

成功のときはバックグラウンドの完了イベントかなんかで処理するとか

色々あると思うけど

702:デフォルトの名無しさん
09/08/07 17:25:47
Microsoftの決めたことなんだから正しいお

703:デフォルトの名無しさん
09/08/07 18:37:58
>>697
吸収してどうしろって？
別プロセスからの例外をプロセス間通信で受け取るの？
それをフレームワークでやれって？

704:デフォルトの名無しさん
09/08/07 19:01:23
なん…だと…

705:デフォルトの名無しさん
09/08/07 20:19:40
Windowsフォームで質問。

Form2 _form2 = new Form2(_form1);

としたとき、_form2.FormClosedのイベントハンドラで_form1.Close()するコードを書くと、
Form2.OnFormClosed()が何度も呼ばれる（つまりFormClosedイベントが何度も発生する）
ようなんだけど、これは仕様？バグ？

仕様だとしたらどう理解したらいいんだろう？

706:デフォルトの名無しさん
09/08/07 20:25:45
OwnerはCloseするときOwnedFormsを全部Closeする
って言えば分かる？

707:デフォルトの名無しさん
09/08/07 20:34:10
>>706
そのレベルの話はOK

708:デフォルトの名無しさん
09/08/07 20:53:58
普通に再帰呼び出しになってるだけっしょ
止まるのはハンドルが消えるから

709:デフォルトの名無しさん
09/08/07 20:59:15
>>708
現象の説明としてはそれでいいと思うんだけど、
俺が聞きたいのはそういうことじゃなくて、それが仕様なのか、
仕様だとしてそれに何らかの意味があるのかってこと。

FormClosedイベントの意味は、「Close()が呼ばれました」ではないはずだよね。

710:デフォルトの名無しさん
09/08/07 21:06:03
> FormClosed イベントは、ユーザー、Close メソッド、または Application クラスの Exit メソッドによって
> フォームが閉じられた後に発生します。
「Form.Closeが呼ばれました」でも大体いいんじゃないかな

ま、おいらはMSの人じゃないので意味とか答えられないけど

711:デフォルトの名無しさん
09/08/07 21:09:46
>>710
それはさすがに読解力マズいんじゃないかと思うけど。。

712:デフォルトの名無しさん
09/08/07 21:50:30
何度も呼ばれるって何度？

713:デフォルトの名無しさん
09/08/07 21:52:55
バグだよ、>>705のプログラムのね

714:デフォルトの名無しさん
09/08/07 21:55:57
Closed≠Disposedと理解すれば良い

715:デフォルトの名無しさん
09/08/07 22:07:36
>>710-711
MSDNの説明から読み取れるのは

・ユーザ操作、Close()、Application.Exit()で発生しうる
・FormClosedが発生した時点ではフォームは閉じられている

の2点だけじゃね？

てか、説明が怪しいと感じたら英語版を読むといい
それでも怪しいときも多いけどな

716:デフォルトの名無しさん
09/08/07 22:20:48
ちなみに何回くらい呼ばれるの？
また毎回同じ回数なのか場合によって変わるのかどんな感じ？

717:デフォルトの名無しさん
09/08/07 22:33:34
>>716
以下が問題を再現する最短のコード。
コンストラクタは省略してある。

public partial class Form1 : Form
{
　　Form2 _form2;

　　protected override void OnLoad(EventArgs e)
　　{
　　　　base.OnLoad(e);
　　　　_form2 = new Form2();
　　　　_form2.FormClosed += new FormClosedEventHandler(_form2_FormClosed);
　　　　_form2.Show(this);
　　}

　　void _form2_FormClosed(object sender, FormClosedEventArgs e)
　　{
　　　　Close();
　　}
}

public partial class Form2 : Form
{
　　int _count = 0;
　　protected override void OnFormClosed(FormClosedEventArgs e)
　　{
　　　　base.OnFormClosed(e);
　　　　Console.WriteLine("Form2.OnFormClosed Called ! // count = {0}", _count++);
　　}
}

718:デフォルトの名無しさん
09/08/07 22:53:53
>>717
とりあえずDisposedイベントでForm1.Closeやるように変更したら
現象回避出来たぞ

719:デフォルトの名無しさん
09/08/07 23:00:06
>>718
うん、それはわかるけど、
俺が知りたいのはこういうコードを書くと「何故」そんなことになってしまうか、なんだ。

普通に考えれば、OnFormClosedが何度も呼ばれるのは理解に苦しむと思うんだが。

720:デフォルトの名無しさん
09/08/07 23:00:45
Form2ClosedでForm1Closeして新しいClosedが発生するのがおかしいと言ってるの？
何がおかしいのかよくわからない

721:デフォルトの名無しさん
09/08/07 23:02:44
>>719

まあ所持関係にあるForm同士として呼び出してるんだから
＞　　　　_form2.Show(this);

Form1閉じる→Form2閉じる
っていうのは標準動作として組み込まれてる

逆方向の動きを追加したい場合(Form2閉じる→Form1閉じる)は
標準の動作と競合しないようにしなきゃ不具合が起きて当たり前

FormClosed()の時点ではForm同士の所持関係を破棄していないようなので
無限ループが起きる
Disposed()の時点でForm同士の所持関係を破棄しきったので
やりたい動作が実現できる

722:デフォルトの名無しさん
09/08/07 23:07:42
FormClosedイベントなんだから、「完全にフォームが閉じた後」に発生しないとおかしい
と言いたい訳か。
んで_form2が完全に閉じた後だから、_form2_FormClosedが呼ばれても子フォームのCloseが呼ばれるのはおかしい、と

723:デフォルトの名無しさん
09/08/07 23:15:06
Close()をこうやって呼べばいけるっちゃいける。
this.BeginInvoke((MethodInvoker)　(()　=>　Close()));

親フォームが子フォームを閉じるための参照のコレクションを持ってて、
親フォームから登録を抹消するタイミングがFormClosedの後なんだろうな。

724:デフォルトの名無しさん
09/08/07 23:16:44
>>722
＞_form2が完全に閉じた後だから、_form2_FormClosedが呼ばれても子フォームのCloseが呼ばれるのはおかしい、と
いや、そこは必ずしもそうは思わないけど、>>717のコードの動作が「おかしい」と思う点は、
何度も言うけどOnFormClosedの呼ばれ方が、MSDNに書かれたFormClosedイベントの仕様に
反するように思える点。

725:デフォルトの名無しさん
09/08/07 23:17:10
>>723
なんかそれタイミング次第で
うまく行ったり例外おきたり
危険な動作しそうな気がする

726:デフォルトの名無しさん
09/08/07 23:18:43
例えば、Form.Show()は何度でも呼べるけど、
その都度Shownイベントが発生したりはしないよね。

727:デフォルトの名無しさん
09/08/07 23:19:47
>>724
Formのオーナーシップの関係で
Formクラスから子FormのCloseが呼び出されるってことでしょ
何も反してないよ

728:デフォルトの名無しさん
09/08/07 23:23:40
>>727
だから、FormClosedイベントの意味、つまり仕様は、「Closeメソッドが呼ばれました」
ではないよね。少なくともMSDNライブラリを詠む限り、そうは読み取れない。

729:デフォルトの名無しさん
09/08/08 00:26:58
お前が明示的に呼んだときしかCloseメソッドが呼ばれないと思ってるということか

730:デフォルトの名無しさん
09/08/08 00:37:46
>>729
こんなこと言いたくないが、馬鹿はすっこんでてくれよ。
二重の意味で日本語も読めないのかまったく……

731:デフォルトの名無しさん
09/08/08 00:40:59
>>730
どう見てもお前の方が馬鹿だが

732:デフォルトの名無しさん
09/08/08 00:41:33
むしろMSDライブラリを読み取れないレベルの馬鹿がやめた方がいい
お話になりません

733:デフォルトの名無しさん
09/08/08 00:59:09
横やりだが>>728とかの言ってることは別にそんなおかしくないぞ。
Closeを何度呼ぼうが、実際に閉じたタイミングで一度だけ発生する
と期待するのは普通の感覚。
MSDNの説明も普通に読めばそうだと期待する。

一度しか呼ばれない、とは明記されてないし結局仕様なんだろうとは思うけど。

734:デフォルトの名無しさん
09/08/08 01:05:38
1度テストしてみて理解できないようなら方法は無い

735:デフォルトの名無しさん
09/08/08 01:14:25
MSDNのクラスのドキュメントって
クラス単体の動作を説明してるのが基本であって
フレームワークの中でそのクラスがどう扱われてるかは
オマケ程度にしか説明されていない

っていうことをわかって無いから的外れなこと言い出すんだよね

736:デフォルトの名無しさん
09/08/08 01:28:44
>>735
ほほう、「的外れ」とは？
具体的に何がどう「的外れ」だ、と？

いや、無理しなくていいよ。
そんな自分の頭で理解していることを表現しているとは思えない、
悪いけど意味不明な文章を書いているようじゃたぶん正面からの回答は無理だと思うから。

しかし、別に初心者が悪いと思わんけど（誰だって最初はそうだし）
知りもしないことに口出しして挙句に相手をいきなり罵倒する奴っていうのは
迷惑以外の何者でもないな本当。

初心者どころか自分でイベントを生成するコードすら書いたことすらないのが、
言っちゃ悪いがミエミエなのに。
まあそれ以前に日本語もまともに読めていないようだけどw

2chでこんなこと言ってみても仕方ないのは分かっているが、あまりに腹が立ったのでね。

737:デフォルトの名無しさん
09/08/08 03:20:05
ここでクダ巻いててもしょーもねーだろｗ

738:デフォルトの名無しさん
09/08/08 04:57:36
長文書いたら負けですよ

739:デフォルトの名無しさん
09/08/08 06:37:29
閉じられる理由位見ろ
_form2_FormClosed() の処理が
if (e.CloseReason == CloseReason.UserClosing)
　　Close();
じゃないの点が問題なんだよ

何度も Form2 に FormClosed が送られてくるのも
あくまでも Form2.FormClosed イベントが終了していない段階で
Form1 を改めて閉じようとしているからループしてるに決まってるだろ

ユーザ操作以外ではどうせ親から Close が送られてくるから無視でいい

740:デフォルトの名無しさん
09/08/08 16:24:06
Form 1 の中で生成した Form2 を破棄しようとして起きるんじゃないの

741:デフォルトの名無しさん
09/08/08 18:41:56
テキストボックスやパネルの境界線の色をグレーや薄いブルーなどにするにはどうすればいいですか？
また、
ラベルの上に小さめのテキストボックスを重ね、一つのコントロールにすることはできますか？

調べましたが分かりませんでした。
どなたか教えてください
(T_T;)。

742:デフォルトの名無しさん
09/08/08 19:08:28
WPFをつかっとけ

743:デフォルトの名無しさん
09/08/08 19:45:28
>>742
WindowsフォームアプリケーションでWPFのコントロールを使えるんだっけ…。

744:デフォルトの名無しさん
09/08/08 19:50:05
>>740
ユーザ要求により Form2 に WM_CLOSE が送られ
その処理中に Form2 から Form1 に WM_CLOSE が送られ
Form1 が閉じる際に子ウィンドウに対して WM_CLOSE が送られ
その処理中に Form2 から Form1 に WM_CLOSE が送られ……

WM_CLOSE から発生する一連の処理が終了してない間に
改めて WM_CLOSE を流したらループするだろ

745:デフォルトの名無しさん
09/08/08 19:51:38
>>743
Windows Forms の編集時にツールボックス見たら
WPF 相互運用機能グループに ElementHost あるでしょ

746:デフォルトの名無しさん
09/08/08 19:56:57
>>717の場合は、別にWin32のウィンドウメッセージの水準で連鎖が起こってるわけじゃなく、
あくまで.NET Frameworkの、いわゆる「イベントの連鎖」が起こってるだけ
（しかも仕様というよりバグが原因ぽい）だから、ちょっとその説明は違うと思うけど。

747:デフォルトの名無しさん
09/08/08 19:57:05
なんでElementHost なんてわけわからん名前にしたんだ？

748:デフォルトの名無しさん
09/08/08 20:09:08
至って普通の名前だと思うが･･･

749:デフォルトの名無しさん
09/08/08 20:11:01
わけわからんって。
Element(UIElement) を Host するから ElementHost。

750:デフォルトの名無しさん
09/08/08 20:14:18
WinFormだけでやるなら、
TextBoxやらはボーダーなしにして、
その親としてPanelを用意して、
そのPanelのPaintで枠を描画

751:デフォルトの名無しさん
09/08/08 20:15:37
このスレはMS信者に乗っ取られているようだ
嘆かわしい

752:デフォルトの名無しさん
09/08/08 20:31:56
まぁC#使ってる奴の99.9%がMS使いだと思うよ(´・ω・｀)
だれかC#でiPhone開発してる人来ないかな･･･

753:デフォルトの名無しさん
09/08/08 20:34:52
というかどこから >>751 が出てきたんだ？

754:デフォルトの名無しさん
09/08/08 20:44:26
何かのキーワードに反応するボットじゃない？

755:デフォルトの名無しさん
09/08/08 21:12:16
>>750
PanelにPaintができるの？
枠線入りの画像をパネルの背景にするってこと？

756:デフォルトの名無しさん
09/08/08 21:17:07
普通にPaintできるだろ
もしWPFを使うなら，テキストボックス一つ一つをElementHostでホストするようなことはお勧めしない
ある程度の大きい範囲で丸ごとWPFにしてElementHostに乗せる

757:デフォルトの名無しさん
09/08/08 21:28:28
>>755
具体的にどうやるの？
panel1_iventが出てきたけど…。

758:デフォルトの名無しさん
09/08/08 21:45:35
paintイベントって、formをloadしたときに自動で発生するの？

759:デフォルトの名無しさん
09/08/08 21:51:23
描画が必要なとき
もちろん初めにフォームを表示するときも呼ばれるな

760:デフォルトの名無しさん
09/08/08 21:51:35
くれくれしすぎは

761:デフォルトの名無しさん
09/08/08 22:14:24
もしパネルやテキストボックスがたくさんある場合、
それらの全ての四辺を描画するならば、
重たくなりそう。

762:デフォルトの名無しさん
09/08/08 22:16:19
>>756
ラベルやテキストボックスにbordercolorがないのが困る。

763:デフォルトの名無しさん
09/08/08 22:17:19
>>756
エレメントホストはどれくらい重たいのかな。
今からやってみよ。

764:デフォルトの名無しさん
09/08/08 23:01:35
>>741
なんかまともにレスする奴がいないんで見てられないからレスするけど、
そんなのは普通にTextBoxを継承してカスタムコントロール作ってやればいいんだよ。
class TextBoxEx:TextBox
{
　　public TextBoxEx()
　　{
　　　　BorderColor = Color.Red;
　　　　BorderStyle = BorderStyle.FixedSingle;
　　}

　　[Category("Design"), DefaultValue(typeof(Color), "Red")]
　　public Color BorderColor { get; set; }

　　[Browsable(false),
　　DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
　　public new BorderStyle BorderStyle
　　{
　　　　get { return base.BorderStyle; }
　　　　set { base.BorderStyle = value; }
　　}

765:デフォルトの名無しさん
09/08/08 23:02:47
* 764続き *

　　protected override void WndProc(ref Message m)
　　{
　　　　base.WndProc(ref m);
　　　　const int WM_PAINT = 0xF;
　　　　switch (m.Msg)
　　　　{
　　　　　　case WM_PAINT:
　　　　　　　　using (Graphics g = CreateGraphics())
　　　　　　　　{
　　　　　　　　　　using (Pen pen = new Pen(BorderColor))
　　　　　　　　　　{
　　　　　　　　　　　　Rectangle rect = ClientRectangle;
　　　　　　　　　　　　rect.Width -= 1; rect.Height -= 1;
　　　　　　　　　　　　g.DrawRectangle(pen, rect);
　　　　　　　　　　}
　　　　　　　　}
　　　　　　　　break;
　　　　}
　　}
}

766:デフォルトの名無しさん
09/08/08 23:09:41
>>765
細かいことだけど、WndProcよりもOnPaintのオーバーライドのほうが簡潔では？
もちろんsuper.OnPaint呼ぶ手間含んで。

767:デフォルトの名無しさん
09/08/08 23:09:50
>>765
すごい。ありがとうございます。がんばって解読します。
この継承クラスをまた継承したら、命令を抑えてコーディングできますね。

※ なんで継承したら、bodercolorが出てくるんだろう---。

768:デフォルトの名無しさん
09/08/08 23:10:55
>>766
やってみればわかるよ。

769:デフォルトの名無しさん
09/08/08 23:12:08
例えば50個のテキストボックスを表示させ、
それら全てに色枠線を描いたら、重たいのかな。

770:デフォルトの名無しさん
09/08/08 23:30:00
>>768
ごめんなさい。言うとおりだった。

ググったらこんな記述も見つけた。PaintイベントがないならOnPaintもなくて当然か。
URLﾘﾝｸ(msdn.microsoft.com)
> TextBoxBase.Paint イベント
> コントロールが再描画されると発生します。このクラスでは、このイベントは使用されません。

771:デフォルトの名無しさん
09/08/08 23:35:45
panelならOnpaintも可能なんだろか。

772:デフォルトの名無しさん
09/08/09 07:46:49
>>765
さんの記事に、
「using (Pen pen = new Pen(BorderColor)) 」
という行がありますが、using句は名前空間の定義のみに使用するわけではないのですか？
どういうケースでusing句を指定するケースがあるのでしょうか。

773:デフォルトの名無しさん
09/08/09 07:47:50
URLﾘﾝｸ(msdn.microsoft.com)
MSDNくらい読めよクソタコ

774:デフォルトの名無しさん
09/08/09 07:54:42
>>765
using (Graphics g = CreateGraphics())
{
　using (Pen pen = new Pen(BorderColor))
　{
　}
}

だとネストが深くなるから

using (Graphics g = CreateGraphics())
using (Pen pen = new Pen(BorderColor))
{
}

の方がいいな。

775:デフォルトの名無しさん
09/08/09 07:56:28
}それならこれでいいだろ
using (Graphics g = CreateGraphics(), Pen pen = new Pen(BorderColor))

776:デフォルトの名無しさん
09/08/09 09:16:17
>>775
そうやって並べると見辛くないか？ >>774でいいじゃん

777:デフォルトの名無しさん
09/08/09 10:00:28
わざわざ1行にする意味ないな

778:デフォルトの名無しさん
09/08/09 10:26:24
「黄金分割」<副題> ピラミッドからル・コルビュジェまで柳亮著美術出版社
1965年の出版でしかも純粋な美術書。でも、なぜフィボナッチ数の課題を
出されるのかピンとこないプログラマは一度目を通してみるとよい。

779:デフォルトの名無しさん
09/08/09 11:14:40
黄金分割なんてうさんくさいと思うのは俺だけか？

780:デフォルトの名無しさん
09/08/09 12:15:28
みんなが黄金といっているのだから黄金なんだろう

781:デフォルトの名無しさん
09/08/09 12:23:24
僕には黄金はまだきついので聖水でいいです

782:デフォルトの名無しさん
09/08/09 13:30:33
名前が胡散臭いだけで特別なものでも不可思議なものでもないけどね。

783:778
09/08/09 17:47:10
>>779すみません。これ誤爆でした。

784:デフォルトの名無しさん
09/08/09 18:35:56
>>775
コンパイル

785:デフォルトの名無しさん
09/08/09 19:08:36
>>765
こうやると枠線だけ書いて、中の文字塗り潰してしまうイメージあったけど
これでいけるんだ

勉強になりました

786:デフォルトの名無しさん
09/08/09 19:13:38
このやり方で重たくならないならば、俺もやりたい。
みんな、なんでそんなに詳しいの？
頭脳を分けてほしいよ。

787:デフォルトの名無しさん
09/08/09 19:14:55
もっと簡単にできたとおもうが。

788:デフォルトの名無しさん
09/08/09 20:23:35
listviewのcustomdrowめんどくさー

789:デフォルトの名無しさん
09/08/09 20:27:50
ユーlistviewつくっちゃいなYO!

790:デフォルトの名無しさん
09/08/09 20:33:28
customdrow？

791:デフォルトの名無しさん
09/08/09 20:37:31
カスタムドローで合ってるぞ
オーナードローじゃないぜ

792:デフォルトの名無しさん
09/08/09 20:44:39
dr o w?

793:デフォルトの名無しさん
09/08/09 21:05:54
>>784
このロジックはどこに書くの？
デザイナーズcs？
それとも本体の方？

794:デフォルトの名無しさん
09/08/09 21:39:42
いろいろ作ったらさ
SS見せてほしいんだけどｗ

795:デフォルトの名無しさん
09/08/09 22:21:54
>>794
SSってなに？

796:デフォルトの名無しさん
09/08/09 22:24:17
Secret Service

797:デフォルトの名無しさん
09/08/09 22:26:35
SQLサーバーを借りてるんですが、直にSQLを書くのと、linqを使うのと、どちらがメリットが高いですか？

798:デフォルトの名無しさん
09/08/09 22:28:15
ボーリングのスコア表をＣ♯で作りたいんだけど、
膨大な数のテキストボックスを早く負担なく描くには何かいいテクニックはありますか？

799:デフォルトの名無しさん
09/08/09 22:29:39
>>798
なんでボーリングスコア表なんていんねん。

800:デフォルトの名無しさん
09/08/09 22:31:47
>>798
マウスを使って一つずつペタペタ描く。
それしかないだろ。
本を見てもそう書いてた。
間違っていたらごめん。

801:デフォルトの名無しさん
09/08/09 22:40:38
手っ取り早いのはGirdじゃね

802:デフォルトの名無しさん
09/08/09 22:45:24
>>801
ジードって読むの？
初めて聞きました。
詳しく教えてください。
僕もマウスて配置していてくたびれました。

803:デフォルトの名無しさん
09/08/09 22:47:17
1文字間違えるのが流行りなのか？
DateGridView

804:デフォルトの名無しさん
09/08/09 22:48:40
>>800
その本は何個のテキストボックスをポトペしていた？
１０個超えてたらダウト

805:デフォルトの名無しさん
09/08/09 22:59:55
>>804
5つのコマンドボタン。
揃える技は書いてたけど、大量描画についてはコメントなし。

806:デフォルトの名無しさん
09/08/10 00:37:08
ストライクとかのアイコンはどうすんの？
結局自前で描画する予感
なら１枚絵で作ってしまえ！とか

807:デフォルトの名無しさん
09/08/10 00:42:53
DataGridViewはアイコン置けるよー

808:デフォルトの名無しさん
09/08/10 01:34:20
複数の定数を定義したクラスの中に存在する、
定数に要素に全てアクセスするにはどうすればよいでしょうか？
for each 的なコードがあればお教えください。

class TestClass
{

　　public const string const_test_1 = "aaa1";
　　public const string const_test_2 = "aaa2";
　　public const string const_test_3 = "aaa3";
　　public const string const_test_4 = "aaa4";
}

809:デフォルトの名無しさん
09/08/10 01:39:29
設計から見直せタコ

810:デフォルトの名無しさん
09/08/10 01:41:46
>>808
案1　人手で全て列挙を行う
案2　コンパイラの忠告を無視して後々のメンテナンスを全て投げきってもいいならリフレクション

後で人手で行った場合の数倍のツケを支払う覚悟があるなら
機械的にリフレクションを通してもいいかも

811:デフォルトの名無しさん
09/08/10 01:41:54
配列で用意しとけよそんなん

812:デフォルトの名無しさん
09/08/10 01:47:17
>>810
案２の方法をお教えください。

813:デフォルトの名無しさん
09/08/10 01:48:25
>>812
c#　リフレクション　フィールド　列挙
で出てきたの↓
URLﾘﾝｸ(dobon.net)

814:デフォルトの名無しさん
09/08/10 01:50:23
>>813
ありがとうございました。

815:デフォルトの名無しさん
09/08/10 02:11:58
リフレクションなんか馬鹿に勧めるな馬鹿。

816:デフォルトの名無しさん
09/08/10 02:29:09
>>815
馬鹿のお前がいっても説得力がない。

817:デフォルトの名無しさん
09/08/10 02:31:24
リフレクション使って全部実行時に行う必要もなくて

一旦リフレクション使って集計して
その後手作業でソース起こしてもいいかもね

818:デフォルトの名無しさん
09/08/10 07:04:01
yieldでよくね？

819:デフォルトの名無しさん
09/08/10 09:10:28
>>817
これはよくやる
自動生成しちゃえばいいんだよね

820:デフォルトの名無しさん
09/08/10 11:09:01
リフレクションとか難しすぎて頭おかしくなりそう

821:デフォルトの名無しさん
09/08/10 11:26:49
>>819
日本語としては「ひちがつ」が正しいがレッドブックの「なながつ」も間違いではない
ただ朝鮮人や関西人が良く使う「しちがつ」は明らかに間違い
これを使っていると日本人である事を疑われるので気を付けるように

822:デフォルトの名無しさん
09/08/10 11:31:29
>>821
なんか最近BOT多くね？

823:デフォルトの名無しさん
09/08/10 14:27:14
馬鹿ウヨ死ねや

824:デフォルトの名無しさん
09/08/10 20:20:39
lex とか yacc を思いだした

825:デフォルトの名無しさん
09/08/11 00:07:46
リフレクション使うならせめてconstではなくreadonly使おう
constとリフレクションは非常に相性が悪い

826:デフォルトの名無しさん
09/08/11 01:13:45
>>825
もしかしてCLI時点でconst修飾の名前ってきえちゃうの？

827:デフォルトの名無しさん
09/08/11 01:29:13
ビルドした時点でリテラルに置き換わるんじゃなかったか

828:デフォルトの名無しさん
09/08/11 01:31:13
んだよ
だからリテラルにできない物はconst宣言できない

829:デフォルトの名無しさん
09/08/11 01:38:09
使用した場所はリテラルに置き換わってるが、
型の定義としては残っているのでリフレクションで確認できる。

public　static　const　field　System.String　const_test_1

830:デフォルトの名無しさん
09/08/11 01:40:05
ildasmの表記のほうがいいな。

.field　public　static　literal　string　const_test_1　=　"aaa1"

831:デフォルトの名無しさん
09/08/11 01:57:24
しょうがないんだろうけれど、Attributeのコンストラクタ?に普通のオブジェクト生成式とか書けるようになって欲しいお(´・ω・｀)

832:デフォルトの名無しさん
09/08/11 02:26:21
むちゃゆうな
まあ気持ちは分かる

833:デフォルトの名無しさん
09/08/11 08:30:52
Expression<TDelegate>さえ書ければ解決なのに

834:デフォルトの名無しさん
09/08/12 02:27:35
TDelegateってなんだ。

835:デフォルトの名無しさん
09/08/12 06:20:06
Delegateは特殊クラスなのでこういう制約は作れないってことだと思う。
class　F<T>　where　T　:　System.Delegate

836:デフォルトの名無しさん
09/08/12 20:09:48
IL 上作れないわけじゃないよ。実際 ECMA335 には
一例として載ってる。
要するにわざと禁止しているものなので理由を考えて
みるといいと思うよ

837:デフォルトの名無しさん
09/08/13 15:52:09
１日分のログを日付フォルダごとに分けて保存していて
一定期間経過したフォルダを
DirectoryInfo.Delete(true)で削除しているんだが
毎日少しずつ削除時間が延びていくんだが
なんか理由知っている人いない？
削除の他にも処理をしているんだが
なぜか削除だけ時間がかかる
IOの問題なのかな？

ちなみに、、、
OS:windows 2003 server R2
Enterprise x64 Edition
Service Pack2

838:デフォルトの名無しさん
09/08/13 16:39:00
普通にコマンドで消した時は遅くないの？

839:デフォルトの名無しさん
09/08/13 20:45:04
削除してる間にログを他者が見てるって事はないの？
そもそもログの量、大きさは同じくらいなの？

840:デフォルトの名無しさん
09/08/14 00:23:18
処理内容がわからんから何とも胃炎。
毎日一定時間に処理をしてるんじゃないのか。

削除終了時に終了後から一定時間をセットするなら
削除処理にかかる時間分ずれていくだろ。

841:デフォルトの名無しさん
09/08/14 00:45:25
すいません
vista + C# express edition + excel2007です
参照設定で参照の追加でcom タブでmicrosoft excel5.0をみると
microsoft excel5.0　??????????　と出てるんですけど・・・
これって一体・・・・2007以前のexcel入れれば治るのでしょうか？
とても不安です・・・
壊れてるのかなC#・・・（涙

842:デフォルトの名無しさん
09/08/14 02:03:58
>>837
最初は断片化かな？とか思ったけど、メモリリークな気もする。
C#はジェネリクスとnewで管理されているけど解放されないメモリが
簡単にできちゃうから、仮想メモリにガリガリアクセスして時間が
かかってしまう可能性も否めない。
Process Explorerあたりで確認して、GCのジェネレーション２が
異常にでかいサイズなら解放漏れ(ジェネリクスのClearやDisposeのし忘れ)を
確認してみたらどうだろう。

843:デフォルトの名無しさん
09/08/14 02:06:10
>>842
気になる
これってアンマネージドで管理されているメモリの話？
それともマネージドだが古すぎてpermanent(永久?)領域に直ぐに移されちゃう話？
それとも両方混ざった話？

844:デフォルトの名無しさん
09/08/14 02:13:25
マネージドでしょ

845:842
09/08/14 02:35:11
マネージドの話。
ちょっと怖い書き方をしてしまったけど、要は使わないクラスがどっかで
参照されてるので消されずにメモリが圧迫されてるかも、という事です。
ソートとかで一時領域として使ってたDictionaryに、そのまま参照が残っちゃってて、みたいな。
開発中、デバッガ終了後なかなか処理が戻ってこない時はこの現象が起きてるか
疑ってみたほうがいいかも。と、経験者よりorz

846:デフォルトの名無しさん
09/08/14 05:20:44
DirectoryInfoのインスタンスは使いまわしてるか、毎回newしてるか。
Directory.Delete(String,　Boolean)を使ったらどうか。

847:841
09/08/14 08:32:26
初心板にまわります

848:837
09/08/14 11:20:52
みなさん、ありがとうございます。

>>838
ディレクトリのサイズが32MBぐらいで
普通に"rmdir"コマンドで削除すると1分ぐらいです。

>>839
削除しているのは、数日経過したディレクトリなので
他の人は見てないです。

>>840
日付ごとにディレクトリを作成して
その配下に時間ごとのサブディレクトリを
作成してプロセスごとのログを出力しています。
"日付ディレクトリ"の日付を見て
数日経過していたら削除するという
処理を行っています。

>>842
自分も最初はメモリリークを疑っていました。
ページファイルが1日で5MBずつ増えていますが
そのせいで削除処理が約30秒も伸びるんでしょうか？
削除処理だけで、他の処理は遅くなっていないのも
気になっています。

>>846
毎回newしています。
解放処理は明示的に行っていないので
参照が残ってしまっているのでしょうか？

849:デフォルトの名無しさん
09/08/14 12:18:00
>ディレクトリのサイズが32MBぐらいで
>普通に"rmdir"コマンドで削除すると1分ぐらいです。

850:デフォルトの名無しさん
09/08/14 12:58:35
削除の処理にかかる時間が延びてるってことか

851:デフォルトの名無しさん
09/08/14 13:54:14
32MBで一分ってその時点で遅すぎねーか？

852:837
09/08/14 14:04:49
>>850
そうです。
削除の時間が日々伸びています。

>>851
ディスク上のサイズは204MBでした。
遅すぎですかね？

853:デフォルトの名無しさん
09/08/14 14:07:13
ファイル数くらい書けよ。
エスパーさせんな

854:デフォルトの名無しさん
09/08/14 14:08:40
シャドウコピーとかは有効になってる？

855:デフォルトの名無しさん
09/08/14 14:42:25
ファイル数がきっと膨大なはず
ファイルの数があまりに多いと関連の処理がどんどん重くなる

確かWindowsのファイルテーブルてツリー構造してるの見た目だけで
実際はドライブごとに一つの表があるだけだから
ドライブ内のファイル/フォルダの数が多くなる度に
ファイル/フォルダ絡みのあらゆる動作が遅くなる

間違ってたらごめん

856:デフォルトの名無しさん
09/08/14 15:14:19
NTFSだったらB木使ってるからFAT32よりも格段に速いよ

857:デフォルトの名無しさん
09/08/14 15:22:48
>>856
フォルダの中身ごと削除の時点で全スキャンだし

858:837
09/08/14 15:58:22
>>853
すみません。。
フォルダ数:約9500
ファイル数:約52500
膨大な数ですよね。

>>855
毎回削除する"フォルダ数"/"ディレクトリ数"は
変わらないのですが
それでも段々遅くなるのでしょうか？

859:デフォルトの名無しさん
09/08/14 16:07:16
>>858
数日でそんなに溜まるログとか設計が狂ってる

860:デフォルトの名無しさん
09/08/14 16:10:39
いっその事DBにログ記録しろ

861:デフォルトの名無しさん
09/08/14 16:18:10
単純に一日のログを1ファイルにまとめるだけでも
相当マシになるはず

862:837
09/08/14 17:51:15
みなさん、ありがとうございます。
設計というよりも、そういう仕様なので
仕方ない部分もあるのですが･･･

アドバイスを参考にしたいと思います。

863:デフォルトの名無しさん
09/08/14 18:46:36
それ、プログラム終了させて新たに起動したらあきらかに速度が違う
というのなら、今まで消したファイルもスキャンしてるとかないか？

864:842
09/08/15 01:15:55
>ページファイルが1日で5MBずつ増えていますが
>そのせいで削除処理が約30秒も伸びるんでしょうか？
>削除処理だけで、他の処理は遅くなっていないのも
>気になっています。

その、今の所、日を追うごとに増えているデータってのが
ページファイルだけなら疑ってみる価値はあるかと。
ファイル削除とページングでハードディスクへのリクエストがかち合って
ガリガリ言ってる時間が長くなれば可能性はあるかと。

削除プログラムが常駐プログラムなら一度再起動してみて速度をみてみるのはどうだろう？
それ以前にgen2の値はどうなんだろう？これでリークか否かの答えは出ると思うんだけど。

毎回起動なら、そのページファイルを増やしている別のプログラムをつきとめた方がいいかも。
なんにせよ、そのサーバはリークを起こしているっぽいｗ

865:デフォルトの名無しさん
09/08/16 12:42:56
webbrowserに表示しているHTMLを画像として保存するには、
どのような方法が一番妥当ですか？

クライアントの隠れている部分も含めて画像変換したいので、
PrintScreenではだめです。

866:865
09/08/16 13:00:41
ネットで探してて最初は見つからなかったのですが、
書き込んでからいろいろ見つかってきました。

URLﾘﾝｸ(homepage1.nifty.com)

URLﾘﾝｸ(www.i-tribe.info)

すみませんでした。

次ページ