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
そういう歴史を無視した発言はゆとりだから？