10/03/13 14:37:35
>>516
if (This.Seiyoku >= 95) {
This.Hand.GetTimpo();
for (int i = 0;i < 2000;i++) {
This.Hand.Up();
This.Hand.Down();
}
this.Say("あああああ────");
}
520:デフォルトの名無しさん
10/03/13 14:49:42
MessageBox.Show("ふぅ・・・");
521:デフォルトの名無しさん
10/03/13 15:38:49
2000も要らんだろ。
522:デフォルトの名無しさん
10/03/13 15:50:02
細胞が壊死するぞ。
523:デフォルトの名無しさん
10/03/13 15:50:47
C#を猛プッシュしてるキチガイうぜー
524:デフォルトの名無しさん
10/03/13 15:51:42
おまえらは4でじゅうぶん
525:デフォルトの名無しさん
10/03/13 16:15:33
C#はWindowsのGUIアプリを作るっていう非常に限定された状況でのみ
CやC++より優秀
526:デフォルトの名無しさん
10/03/13 16:18:48
あと初心者にはかなり使いやすい
527:デフォルトの名無しさん
10/03/13 16:49:14
>>519
ウィルスコード確認しました
528:デフォルトの名無しさん
10/03/13 17:07:20
>>526
それはC#のメリットというよりVC#環境限定の話だろ
最初にインテリセンス体験したとき開発者マジキチって思った
529:デフォルトの名無しさん
10/03/13 17:14:36
スニペットのせいで構文覚えられない初心者が多発、という弊害がもれなく付いてくるけどなw
530:デフォルトの名無しさん
10/03/13 17:15:01
ただの補完なら大概の言語で使えるけどね
531:デフォルトの名無しさん
10/03/13 17:16:54
構文を覚える必要はない
532:デフォルトの名無しさん
10/03/13 17:24:03
構文は自然と覚えるものだと思うが
533:デフォルトの名無しさん
10/03/13 17:36:34
構文と言うよりも単語が覚えれないかな
534:デフォルトの名無しさん
10/03/13 17:36:59
スニペットなんてただの初心者騙しの鬱陶しい機能にしか思えないけど、
あんなの活用してる人いるのか
っていうかPEZみたいな名前が気に入らん。
ラムネ菓子かっ
535:デフォルトの名無しさん
10/03/13 17:44:48
>>534
PEZさんディスってんじゃねー
536:デフォルトの名無しさん
10/03/13 17:46:51
楽できるなら楽したらいいと思う
いまさら a += 3 を a = a + 3 って書きたいひとはおらんじゃろ
537:デフォルトの名無しさん
10/03/13 17:46:58
プロジェクト内だけのスニペットは便利だったりする
538:デフォルトの名無しさん
10/03/13 17:53:09
>>536
おまえはおれを怒らせた
539:デフォルトの名無しさん
10/03/13 18:19:07
昔はprop->のproperty作成とかやってたな。
private変数作ってから、crtl+r, ctrl+eのリファクタの方が便利だと知ってからは使わなくなった。
540:デフォルトの名無しさん
10/03/13 20:33:49
よく入力するパターンは自分で定義して使ってるな
dw: Debug.WriteLine( );
eh: (_sender, _e) => { };
とか
541:デフォルトの名無しさん
10/03/13 20:53:42
>>475
なにこのコード
なんでusing使ってるの？
俺がC#触ってない間になんかあったのか
542:デフォルトの名無しさん
10/03/13 20:55:57
どれぐらい使ってなかったんだ
543:デフォルトの名無しさん
10/03/13 20:59:54
IDisposable
544:デフォルトの名無しさん
10/03/13 21:00:20
>>541
button1.Click += (sender, e) => MessageBox.Show("こんなのもできるよ");
545:デフォルトの名無しさん
10/03/13 21:01:47
using構文はC#1.0当初からある構文だが
強いて言うなら>>541が触ってない間に>>541からC#の記憶が飛んだんじゃないか
546:デフォルトの名無しさん
10/03/13 21:50:11
最初から知らなかっただけだろう
547:デフォルトの名無しさん
10/03/13 22:00:41
2.0からだと思ってた俺
548:デフォルトの名無しさん
10/03/13 22:03:58
>>512
（´；ω；｀）
549:デフォルトの名無しさん
10/03/13 22:10:03
2.0からだろ
550:デフォルトの名無しさん
10/03/13 22:12:35
>>544
ラムダ士気って便利だよね。
551:デフォルトの名無しさん
10/03/13 23:14:10
ちょっと教えてください
文字列が入ったリストデータをTreeViewに表示する場合
TreeViewを継承した自作クラスにリストデータを直接読み込んで表示するようなメソッドを作るべきか
TreeViewのNodesに追加する処理をForm1でするべきか
どちらがいいのでしょうか?
552:デフォルトの名無しさん
10/03/13 23:17:31
その程度なら後者
553:デフォルトの名無しさん
10/03/13 23:23:28
>>551
どっちでもいいんじゃね？
なんでもかんでもFormに書くのもあれだし継承してあれこれ作れるならそういう練習を兼ねて別途設計してもいいだろうし
554:デフォルトの名無しさん
10/03/13 23:28:22
練習も兼ねて自作クラス作ってみようと思います
ありがとう
555:デフォルトの名無しさん
10/03/14 01:10:52
うむ
556:デフォルトの名無しさん
10/03/14 03:31:22
フォームアプリで処理内容を表示したいのですが
Form1の処理内容ならtextboxなどに表示すればいいですが
form1でインスタンス化したオブジェクト内部の処理内容を表示したい場合
どうすればいいでしょうか?
557:デフォルトの名無しさん
10/03/14 03:54:06
オブジェクトに処理状況を返すメソッドを作って
Form1から非同期で動かして定期的に処理状況を調べる
558:デフォルトの名無しさん
10/03/14 07:39:47
非同期･･･ちょっと難しそうですね･･･
諦めます
559:デフォルトの名無しさん
10/03/14 09:42:11
なんでも試してみるもんさ
と、偉大なゲイは言いました
560:デフォルトの名無しさん
10/03/14 11:00:47
もしくはそのオブジェクトに textbox なりを教えてあげて、
オブジェクト内部の処理が終わったら textbox に直に書き換えてさせてしまうとか。
他との兼ね合いがないなら、自分はそうする。
561:デフォルトの名無しさん
10/03/14 11:01:51
BackgroungWorker使えばそこまでめんどくもないと思うんよ
562:デフォルトの名無しさん
10/03/14 11:43:11
スレッドの扱いやすさ考えるとBW使うのめんどくさくてね・・・
563:デフォルトの名無しさん
10/03/14 11:43:44
>>556
>>558のように言ってるって事は、恐らくその「オブジェクト」の処理は
UIと同じスレッドで動くってことなんだろうから、
それなら単純にその「オブジェクト」のクラスに～Changed系のイベントを実装して、
Formの方はその～Changedイベントで表示内容を更新すればいいんだよ。
それが面倒で、かつ更新するコントロールの数が少ないなら、
Formにタイマくっつけてタイマのイベントで表示内容を更新してもいい。
何か難しく考えすぎてないか？
564:デフォルトの名無しさん
10/03/14 12:09:23
ですね
565:デフォルトの名無しさん
10/03/14 12:45:49
>>563
>>560
なるほど､イベントは自前で作った事ないからやってみてもいいかも
簡単なのはtextboxの参照渡すのがいいですね
検討してみます
ありがとうございました
566:デフォルトの名無しさん
10/03/14 12:59:28
なんか初心者が間違った知識を覚えるのをほっとくのも気が引けるんで一応突っ込むけど、
＞簡単なのはtextboxの参照渡すのがいいですね
こういうやり方は普通は邪道とされている。
馬鹿だと思われたくなければやっちゃダメ。
これがダメな一番の理由はそんなことをしちゃうとそれぞれのクラスの
役割分担が明確じゃなくなるから。
TextBoxの更新を担当するのは、その持ち主であるFormであるべきだとは思わない？
他のオブジェクトがTextBox更新しちゃうのなら、Formの役割って一体何よ。
567:デフォルトの名無しさん
10/03/14 14:08:52
それは設計によるとしか言いようがない。
568:デフォルトの名無しさん
10/03/14 14:21:32
ただ機能的要件が果たせさえずればOK、と思いつくままにTextBoxの参照を
渡すような馬鹿で間抜けな行為を「設計」とは言わない。
569:デフォルトの名無しさん
10/03/14 14:22:43
まぁそれをいっちゃうとMVCとかObserverとか面倒なので
570:デフォルトの名無しさん
10/03/14 14:29:27
まあtextboxもクラスだからついついやりがちだけど所詮はGUI部品だからなあ
一番いいのはデリゲートだっけ？
571:デフォルトの名無しさん
10/03/14 14:34:01
563の言うようにするかなあ
その処理オブジェクトは、進捗を公開するかしないかを決め、
GUIオブジェクトは、それを見るか見ないか自由にする
572:デフォルトの名無しさん
10/03/14 14:50:30
前に別スレッドからメインのFormに貼ってあるtextboxにログを吐く方法を聞いたときに
作ったのならあるわ
Form1.cs
URLﾘﾝｸ(codepad.org)
hoge.cs
URLﾘﾝｸ(codepad.org)
hoge.csは自分でクラスを作ってコード張ってくれ
Form1.csの方はtextboxをDock=Fillで張ってスクロールバーを表示しておけばいいか
あとshownで表示させてるのでイベントハンドラ追加してからコード貼ってくれ
573:デフォルトの名無しさん
10/03/14 14:51:23
hogeクラスはスレッド起動部分を書いてないけど移植前の方では動いてるので問題ないと思う。
574:デフォルトの名無しさん
10/03/14 15:06:30
PInvokeでもつかえば
575:デフォルトの名無しさん
10/03/14 15:08:59
P無しで
576:デフォルトの名無しさん
10/03/14 15:10:45
ほうピンボケを
577:デフォルトの名無しさん
10/03/14 15:13:03
関数名をhogehogeにするつもりがhogehoeになってたｗ
hogehoeは本当はスレッド起動をさせる関数なんだけどその辺は端折ったｗ
578:デフォルトの名無しさん
10/03/14 15:23:18
訂正版
URLﾘﾝｸ(codepad.org)
579:デフォルトの名無しさん
10/03/14 15:56:25
URLﾘﾝｸ(codepad.org)
こんな感じで遊んでたんだがApplication.DoEvents入れて経過を分かるようにすると
スレッドの動作が変わった感じなんだが何が変わったんだろう。
Application.DoEvents無し->適度に3スレッドの出力が混じる
Application.DoEvents有り->最初の一回だけ起動した順に結果がでるけど２回目以降は後で起動したスレッドだけ？やってる感じ
580:デフォルトの名無しさん
10/03/14 15:58:05
100x3は多いので10x3に絞ってみた
Application.DoEvents有り
[ 0000 ] 0
[ 0001 ] 0
[ 0002 ] 0
[ 0002 ] 1
[ 0002 ] 2
[ 0002 ] 3
[ 0002 ] 4
[ 0002 ] 5
[ 0002 ] 6
[ 0002 ] 7
[ 0002 ] 8
[ 0002 ] 9
[ 0001 ] 1
[ 0001 ] 2
[ 0001 ] 3
[ 0001 ] 4
[ 0001 ] 5
[ 0001 ] 6
[ 0001 ] 7
[ 0001 ] 8
[ 0001 ] 9
[ 0000 ] 1
[ 0000 ] 2
[ 0000 ] 3
[ 0000 ] 4
[ 0000 ] 5
[ 0000 ] 6
[ 0000 ] 7
[ 0000 ] 8
[ 0000 ] 9
581:デフォルトの名無しさん
10/03/14 17:43:05
あるインスタンスが同じクラスの別のインスタンスに影響を与えるのは悪いことですか？
582:デフォルトの名無しさん
10/03/14 17:45:05
たとえば、Form1の中にButton1とButton2があったとして
Button1.Clickを、Button2のサイズとか名前とかを変える
みたいなイベントにしたら、Button1はButton2に影響を与えてるけど
これっていけないことなの？
インスタンスはすべて独立させたほうがいい
みたいなこと書いてたんだけど
583:デフォルトの名無しさん
10/03/14 17:47:20
>>582
ケースによるんじゃない？
584:デフォルトの名無しさん
10/03/14 17:57:33
そんなこと真面目に聞いてたら無効にしたボタンは二度と有効にできないな
どこでそんなこと言ってたのか興味あるから教えて欲しい
585:デフォルトの名無しさん
10/03/14 18:05:47
Button を継承した Button1 のメソッドで Button2 をいじったらだめだろうけど
実際いじってるのは親の Form なんだから、 Button1 が Button2 に影響を
与えてるわけではない
586:デフォルトの名無しさん
10/03/14 18:10:43
>>556の話はインスタンス化したオブジェクト内部なんで
関係としては>>572>>578>>579あたりのコードのような状態だからなあ
buttonが直接外の何かに影響するってことは標準ではなくて
イベントハンドラを登録して処理は別途書くよね
587:デフォルトの名無しさん
10/03/14 18:12:54
「影響」というのがメソッド呼び出しの事をさしているのであれば、（それ以外にありえないと思うけど）
影響を与えるなというのはメソッド呼び出しするな、と同義になるわけで、
じゃあprivateなメソッドだけを持つ自律的なクラスだけでコードが書けるのかと。
まあ、要するに愚問過ぎるw
>>585
いや意味わからないしw
588:デフォルトの名無しさん
10/03/14 18:48:37
はぁ～い
ちゃぁ～ん
589:デフォルトの名無しさん
10/03/14 18:48:40
アプリ起動時にフォームとフォーム内のコントロールが
ちゃんと表示されてからプログラムが実行されるようにしたい
shownでもフォームが表示されただけでコントロールが
ちゃんと表示されない状態で実行されるのですが
なにか良い方法はないでしょうか?
590:デフォルトの名無しさん
10/03/14 18:52:11
ない。
591:デフォルトの名無しさん
10/03/14 18:54:39
Application.Idleが近いかねぇ
592:デフォルトの名無しさん
10/03/14 18:54:51
ままっままま､まじっすか
593:デフォルトの名無しさん
10/03/14 18:58:10
あるあるよ
594:デフォルトの名無しさん
10/03/14 19:00:40
WebBrowserだとnavigatedイベントなんてあるけどそれと似たようなのって聞いたこと無いな
595:デフォルトの名無しさん
10/03/14 19:03:10
普通はフォームが表示される前に
事前処理を終了させるのかな
他の言語でもこんな感じ?
596:デフォルトの名無しさん
10/03/14 19:04:28
言語の問題じゃなくてWindowsの問題だと思うけどなｗ
597:デフォルトの名無しさん
10/03/14 19:07:45
Formが表示されてからしばらく何か動くのであればshownのタイミングで
Form全体のコントロールを触れないようにして処理した後ユーザーが触れるようにするとか
ちなみにやり方に普通はないよ
ユーザーがフリーズしたんじゃないの？とか
表示されたので触っていいと思ったけどなんか触ったらおかしくなった・・・とか
そういうのを回避できてればいいと思うよ
598:デフォルトの名無しさん
10/03/14 19:13:58
activateかなんかなかった
599:デフォルトの名無しさん
10/03/14 19:20:26
shownだとユーザーがフリーズしたと思われそうだなー
loadイベントで処理する方がマシか
600:デフォルトの名無しさん
10/03/14 19:23:43
うん
601:デフォルトの名無しさん
10/03/14 19:28:16
>>599
Loadでやるにしてもスプラッシュウインドウでも出しておかないといらちにはあれだぜ
いらちをだますには適度なタイミングでちびちび変化を見せてあげるほうがいい
602:デフォルトの名無しさん
10/03/14 19:29:39
ほとんどﾋﾞｮｰｷ
603:デフォルトの名無しさん
10/03/14 19:31:25
>>602
病気だけどそんなのはいえないしねえｗ
604:デフォルトの名無しさん
10/03/14 19:31:47
いやShownでちゃんと表示されてるはずだし。
でなきゃ"Shown"って名前が嘘になっちゃうし。
何がしたくて何を言ってるのかサッパリ意味がわからんな。
605:デフォルトの名無しさん
10/03/14 19:34:57
>>604
FormのShownでしょ
確かに上に乗ってるコントロールはFormのコンストラクタでできてるので
問題はないけどshownの段階ではForm上にのってるコントロールのどれかが
何かしら動いてる？から今回の質問なわけでしょ・・
まあ自分のアプリの処理のタイミング調整でなんとかなりそうだけど
606:デフォルトの名無しさん
10/03/14 19:38:41
>>605
ごめん真面目に何言ってるのか理解できん。
っていうか、それ>>589が言ってることと明らかに違わないか？w
607:デフォルトの名無しさん
10/03/14 19:51:19
>>601
イラチのおれはスプラッシュウィンドウなんて表示しなければ
もっと起動早いだろって思う
608:デフォルトの名無しさん
10/03/14 19:52:05
URLﾘﾝｸ(d.hatena.ne.jp)
これじゃね
609:589
10/03/14 20:00:28
>>608
おお､まさしくこれだ
ありがとう
610:デフォルトの名無しさん
10/03/14 20:01:35
え・・・そんな基本的な話だったの？
611:デフォルトの名無しさん
10/03/14 20:08:12
>>608
ブログ主はなんか勘違いしてるな
Appliation.DoEvents()って、そんなもので自分のいってる問題が
本当に解決してると思ってるのかw
悪いけどおめでたすぎるわ。
612:デフォルトの名無しさん
10/03/14 20:09:57
>>611
ではズバリ教えて
613:589
10/03/14 20:13:33
Application.DoEvents()すげーー
ループ処理の中に記述しただけで
今までListViewが随時更新されずに､処理後結果が一気に表示されてたのに
リアルタイムで再描画してるーーー
これをあっちこっちに入れるとしあわせだな
614:デフォルトの名無しさん
10/03/14 20:14:31
でもそれやると処理が遅くなるけどね
615:デフォルトの名無しさん
10/03/14 20:18:38
>>612
OnShown()なりOnLoad()なりでApplication.Idleとかに紐付けするのが
正攻法だとは思う。
内緒だが、同じことを簡単にやる方法としてはthis.BeginInvoke()を使う、
なんて手もあったりする。
まあ、これってそもそも下らない問題意識だと個人的には思うけどね。
>>589
Application.DoEvents()なんか必要もないのに（必要な場面がそうあるとも思えんけど）
VB厨って言われるよ。
それはともかく、明らかに悪い作法だ。
616:デフォルトの名無しさん
10/03/14 20:22:16
DoEventsはおかしな動作する元だからな
617:デフォルトの名無しさん
10/03/14 20:22:44
DoEventsやるとメッセージ処理されるから順番が逆になったり弊害が出る
618:589
10/03/14 20:24:43
え･･･
WEBからファイル落とすときにフリーズ状態になるので
Application.DoEvents()で描画更新されるようになったんだけど
本当は非同期でやるべきなんだおろうけど
619:デフォルトの名無しさん
10/03/14 20:28:15
>>618
そう端的に言って努力の方向が間違ってるよ。
620:デフォルトの名無しさん
10/03/14 20:31:19
WebからファイルってAsyncあるだろーが
621:デフォルトの名無しさん
10/03/14 20:46:33
＞SystemException は、ユーザープログラムで回復できる致命的ではないエラーが発生した場合に、共通言語ランタイムによってスローされます。
とのことだが、キャッチして回復しようとすると「CA1031汎用的な例外をキャッチすんな」って怒られるんですけどどうしろと
HAL9000もバグっちゃうよ
622:デフォルトの名無しさん
10/03/14 21:01:25
ああ、もうSystemExcpetionとかApplicationExceptionとか過去の話だから
623:デフォルトの名無しさん
10/03/14 21:05:39
俺の問題解決にはすべて非同期プログラミングの習得するか否かにかかってるとみた
私はあえてこの高度なアルゴリズムに挑むことにする
すべてはより高度なアプリを開発するために
624:デフォルトの名無しさん
10/03/14 23:08:51
Console.WriteLine("{0}",intA)
この書式をtextBoxに表示するのに利用するにはどうすればいいですか？
625:デフォルトの名無しさん
10/03/14 23:10:38
String.Formatとかどう？
626:デフォルトの名無しさん
10/03/14 23:13:41
intA
これって文字通りintの変数？
だったら
textBox1.Text += intA.ToString();
とか
textBox1.AppendText(intA.ToString());
とか
数字の出力パターンを変えたい場合はintA.ToString("0000")
とかすればいいよ
この辺は調べて
627:デフォルトの名無しさん
10/03/14 23:47:39
>>625
これこれ､こういうのがほしかった
ありがとう
628:デフォルトの名無しさん
10/03/15 00:30:11
クラスが10個ぐらいになるともうわけわかめ
UML導入するか
629:デフォルトの名無しさん
10/03/15 00:33:13
UMLでどうにかなる問題じゃないだろ
10個程度のクラスの相関を把握できないでどうするよ
630:デフォルトの名無しさん
10/03/15 02:22:09
わけ分からない→じゃあUMLだ、という発想がｲﾐﾌ。
これまでドキュメントとか無かった現場なんだろか。
631:デフォルトの名無しさん
10/03/15 03:25:13
そうだよ
632:デフォルトの名無しさん
10/03/15 03:27:51
ユーザーが数字ではなく文字を入力した場合のエラーの取得はこういう感じでいいのでしょうか?
それともUserInputクラス内ではtry文を使わないでProgramクラスだけでやったほうがいいんでしょうか?
public class UserInput
{
public int Input()
{
int a = 0;
try
{
a = Int32.Parse(Console.ReadLine());
}
catch (Exception e)
{
throw e;
}
return a;
}
}
633:デフォルトの名無しさん
10/03/15 03:28:32
>>632の続き
class Program
{
static void Main(string[] args)
{
UserInput ui = new UserInput();
try
{
int b = 0;
b = ui.Input();
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
}
634:デフォルトの名無しさん
10/03/15 04:54:15
>>632
catch { throw; }
とか何がしたいんだか分からんw
635:デフォルトの名無しさん
10/03/15 05:52:59
(ﾟ∀ﾟ)
636:デフォルトの名無しさん
10/03/15 05:53:23
右から左に受け流したいんだろう
637:デフォルトの名無しさん
10/03/15 06:49:17
左から右へ受け流すのはゆるさないからなｗ
638:デフォルトの名無しさん
10/03/15 11:59:14
わざわざコケさせなくてもTryParseとかあるし
639:デフォルトの名無しさん
10/03/15 12:10:41
例外ロンダリングだよ。
640:デフォルトの名無しさん
10/03/15 13:41:01
入力された文字が数字だけかどうかって面倒なら
Convert.ToInt32(textBox1.Text)
とかやってtry catchで判断すればOKだよ
641:デフォルトの名無しさん
10/03/15 13:58:55
try catchなんてするくらいならTryParseでいいだろ
って話だ
642:デフォルトの名無しさん
10/03/15 14:14:23
ＴｒｙCatchなんかでやってたらエラー時のスタック解析の時間とか入れたら劇遅になるじゃねぇか
643:632
10/03/15 14:23:37
すいません､これは単純なモデルで表現したくてやったので
この場合だとTryParseを使ったりすればいいですが
本当に聞きたかったのは
ファイル入出力時のエラーや､WEB操作時のエラーや
オブジェクトがnullだったりなど､Formとは別のクラス内部のエラーが
あった場合に別クラスの内部で例外処理をするのか
Form上で例外処理をするのかがよくわからないんです
一般的にどういうやり方をするのか聞きたかったのですが
うまく説明できなくてすいません
644:デフォルトの名無しさん
10/03/15 14:26:32
.net時代のエラー処理ってやつですかね？
C/C++時代だと暴走の元なのでポインターがnullかどうかチェックしたりとかやってたようなのをどうしてるのか？
ってところ？
645:デフォルトの名無しさん
10/03/15 14:29:44
例外もみ潰しても続行できるなら内部で処理
できないなら外に投げる
646:デフォルトの名無しさん
10/03/15 14:38:08
お前らって例に噛み付くよね。
例えばの話に本気になってどうするの。
647:デフォルトの名無しさん
10/03/15 14:44:48
一事が万事という
小事に本気になれない奴がどうして大事に本気になれようか
648:デフォルトの名無しさん
10/03/15 14:50:34
（＾ω＾；）
649:632
10/03/15 15:05:46
>>644
多分そういう感じです
例えばフォーム上であるクラスのメソッドを呼び出して
nullが返ってくる場合もあるし､例外で投げられる可能性もあります
ResCollection thread_Honbun=bbs.ReadRes(url); ←例外がでる可能性
thread_honbunを利用 //←nullで例外がでる
なぜこういう質問するかというと
別クラス内部でいくら例外処理をしたところで
結局利用する側のformでやはり同じような例外処理を
しなければならないのでみなさんはどうしているのかと思いまして
650:デフォルトの名無しさん
10/03/15 15:14:43
まずnullをなるべく返さない所から始めたらいいと思うよ。
651:デフォルトの名無しさん
10/03/15 15:32:36
>>649
CodePlexで他人の書いたコード（なるべくメンバーの多い奴がいい）でも読んでみるといいよ
うんこ漏れそうなくらいtrycatch使いまくりだから
例外は昔の言語のnullチェックとエラー値チェックの代替機能なんだから
エラーチェックそのものをを省くための手段じゃないのよ
目的にしているのはエラーに対して画一的に対処できることね
例えばWin32APIにはnullを返すものもあれば、INVALID_HANDLE_VALUEを返すものもあるし
E_OK、E_SUCCESSなんてのを返すのもある
これら全部例外として括ってしまおうって趣旨だから
652:デフォルトの名無しさん
10/03/15 15:37:53
うんこは漏れない。
653:632
10/03/15 15:42:58
つまりちゃんとデータを返すかもしくはエラーを返すかの
2通りにするほうがいいということかな
確かに今のソースはnullかどうかをform側でも別クラスでも
条件分岐で何重にもやっている状態でしかもやってない場合もあったりと
かなりごちゃごちゃしてます
C#しかやったことないけど､自分は古いやり方をしていたということなのかな
他人のコード見て勉強してみます
どうもありがとう
654:デフォルトの名無しさん
10/03/15 15:56:14
エラーコードを例外に置き換えるリファクタリングを思い出した
655:デフォルトの名無しさん
10/03/15 16:02:52
この辺か
Replace Error Code with Exception
URLﾘﾝｸ(www.refactoring.com)
Replace Exception with Test
URLﾘﾝｸ(www.refactoring.com)
656:デフォルトの名無しさん
10/03/15 16:06:21
これはうんこ漏れるわ
657:デフォルトの名無しさん
10/03/15 16:06:58
まあ続行しても意味がないようなところで出るエラーはtryで拾ってもいいんじゃねーの？とか思うけどな
コストがかかるとか言っても継続できねーんだからいいだろうと・・・
658:デフォルトの名無しさん
10/03/15 16:30:09
テーブル 部
コード 名前
01 営業部
02 開発部
テーブル課
部コード 課コード 名前
01 01 第一営業
02 01 第一開発
テーブル社員
部 課 名前
01 01 山田太郎
といった データ構造で
社員をDataGridViewにデータバインドで表示する場合、
DataGridViewComboBoxColumを用いて課を表示することはできるでしょうか？
部テーブルは一意キーなので表示できますが
課テーブルは複数キーですので無理ですか？
型付データセットを使っているので、手動で余計なカラムを増やしたくなく、
リレーションをComboBox側のデータバインドでやってしまいたいっていう考えです。
どなたか回答お願いします。
659:デフォルトの名無しさん
10/03/15 17:03:22
ＤＢで取ってきてるなら
部と課をくっつけた一意な文字列のカラムも加工して取ってくるようにして、
課のキーではなくそれにバインドさせたら駄目だっけ?
660:デフォルトの名無しさん
10/03/15 18:41:16
>>572
>>578
>>579
デリゲート使うと非常に便利ですね
参考にさせていただきます
ありがとうございました
661:デフォルトの名無しさん
10/03/15 19:59:42
C#はプロパティがめっちゃ便利だな
変数に代入するのと同時に処理ができるってのはすばらしい
C言語だと同じようなことをどうやってたんだろうな。
Privateとかないからポインタを引数にとって参照私とかやってたんだろうか。
662:デフォルトの名無しさん
10/03/15 20:04:52
C#を作った人物って
Delphiを作った人と同一人物なの？
663:デフォルトの名無しさん
10/03/15 20:07:13
普通にgetter/setterじゃないのか
JavaやC++は今でもそうやってるだろ
664:デフォルトの名無しさん
10/03/15 20:16:09
プロパティなんて無い言語のほうがおかしくて、
無いJava, C++, Perl, Rubyが同化してるとだけ言っておこう
C#との類似性がよく指摘されるVisual Basic, JavaScriptにはプロパティが存在する
あとPHPにもプロパティがある
665:デフォルトの名無しさん
10/03/15 20:19:45
>>664
古い言語にそんなこといっても仕方ないと思うけどｗ
666:デフォルトの名無しさん
10/03/15 20:43:28
>>662
たしかそう
667:デフォルトの名無しさん
10/03/15 20:44:48
>>666
Rubyは新しいぞぞ
668:デフォルトの名無しさん
10/03/15 20:50:30
Jeffrey Richterだったと思うけど、プロパティなんてｲﾗﾈって意見の人もいるんだよね。
俺は同意できんけど
669:デフォルトの名無しさん
10/03/15 20:54:02
リッチャーの本大量に持ってるのに・・・
捨てっかな
670:デフォルトの名無しさん
10/03/15 20:56:23
でも結局は言語作ったおっさんの思想＜多く使われる言語ってことなんだよな
>>664がプロパティ無いって言語は設計も古いし今となってはそれほど拡張もされてないような物だし
C#もそこそこ年数たったけどVBのよい部分は引き継いでるので似てても不思議ではないし
671:デフォルトの名無しさん
10/03/15 21:00:10
>>662
アンダース・ヘルスバーグのことか？
672:デフォルトの名無しさん
10/03/15 21:18:13
>>664
そういう歴史を無視した発言はゆとりだから？