ふらっと C#,C♯,C＃（初心者用） Part135
レス数が950を超えています。1000を超えると書き込みができなくなります。
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part134
http://mevius.5ch.net/test/read.cgi/tech/1511951038/
■関連スレ
C#, C♯, C＃相談室 Part95
http://mevius.5ch.net/test/read.cgi/tech/1508180530/
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>850
どんな環境で何を見て始めたのか知らないけども、
VSならプロジェクト作成から「Windows フォーム アプリケーション」を選んで実行すれば、
空のウィンドウが表示される
初心者ならコマンドプロンプトで作らなくていいんじゃね？ >>850
初心者がIDE入れないでやるのは自殺行為
自称上級者でもメモ帳ではまあまともにアプリなんて作れない
IDE入れる
本を買って来て手順を踏む
5年たったらメモ帳でアプリ製作に挑戦 c#はどの場面でもメインにはなれないけど隙間隙間でやっていくだろう >>850
おそらくSystem.Windows.Forms.dllへの参照が埋め込まれていないんじゃないかと
うちの環境だとIDE入ってるせいかSystem.Windows.Forms.dllへの参照は勝手に入るが
コンパイルエラーコードはこの辺りに纏まっている
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/compiler-messages/CS0234
といってもVSはVSでエラーコードに関してヘルプをBingで検索しだす奇天烈仕様 azureの知識とかどうやってつければええのですん？ 回答ありがとうございます
実際の対策としてVS導入はするつもりですが、
知識欲として、参照が埋め込まれていない状態をＩＤＥ介さずに解消するのは難しいのでしょうか？ >>857
コンパイラスイッチで参照追加すればいいよ >>848
> javaでもphpでもrubyでも
よりによってなんでそんなアホな選択肢なんだよ w > 今時Webできない開発者なんかいない
Webやってるのって少数派じゃねーの。使い捨て技術者のイメージ。 >>857
ビルドも通らない人間が気にするこっちゃないよ >>861
そんなことはないでしょ。
でも、ドリーマーが多いのは確かだと思う。
なにせ20年ずっと「UIはHTMLの時代になる」って言い続けてるんだからw >>857
csc test.cs -r:System.Windows.Forms.Dll
でもできない？ でも正直なところ一般人の目に付く範囲のアプリってoffice除いたら
大体htmlで構成されてるものが多いんじゃないか
そうじゃなくてもネットワークがないと何も始まらない WEB技術なんか追いかけてたら廃人になると思う
フレームワークが使い捨てだもんな Webの特にフロントエンドはひどすぎるな。JavaScript。
生産性の低い道具を使って仕事たくさん生み出そうってことなんだろう。
俺もReactだけは勉強したけどさｗ
去年のQiitaアドベントみると去年はVue.jsだったのか？ww
アホすぎ 業務系はレイヤー分割下手くそな初心者みたいなSE, PGばっかりだから
フロントを入れ替える=全改修みたいな悲惨な事になるから、頻繁にフロントを変えるって発想ができないんだろう
ここにはどうしても高い文明の壁があるから分かり合えることはない ちょっと流れてしまいましたか、貴重な意見ありがとうございます。
教えていただいたページで勘違いしていたところがスッキリしました。
WPF登場してから時間が立っているからか、古く感じてしまうのは仕方なしなのかな、と思う一報、クライアントアプリを扱う現場ではまだまだ全盛、WinFormも負けてられない勢いで使われているとおもいます。
また、一部、EFはサーバーサイドで…と言う意見もいただきましたが、クライアントでも、問題ないですよね、多分。
というか今回の質問としてはwebでないので3層は意識せず、でもUIとロジックの分離、その先の責務の分離を考えると、良い方法かな、と思いますが…じゃあEF使わないんだったら、どうしよう、constでクエリ定義してDataAdapterにぶっ込む…なんてしたくなかったですし。。。
もう少し調査は必要かもですが、ちょっとやってみたいと思います。 ＞ここにはどうしても高い文明の壁があるから分かり合えることはない
例えばどんなところが「高い壁」といえるんだ？ アセンブラの理解を必要される世界は土人の世界と言える。 高いか低いかそれすらわからない。要するに何もわからないという壁だな。ｗ 本人にとっては高い壁なんだから放っておいてあげなよ アセンブラの理解ってか、論理回路を理解するかどうかじゃね？
ちょこっと弱電をかじれば、なんとなく理解出来ると思うけども >>875
おまえがなんとなく理解出来るんなら大体の人は正確に理解できんじゃね？ アセンブラは何とか成るけど、そのまま１６進数打っていた奴には敵わんかったわｗ
いくら８ビットで命令少ないからって常人が出来るものじゃない >>876
ソフトの原理を理解していれば、
電気回路も大体理解出来るよ。 >>877
こういう話で 8086 のバイトコードを丸暗記していたという話はきいたことがないね >>880
Z80はアドレッシング・モードが簡素なので、手計算でジャンプ先の数字セットできるけど
６８とか８６辺りになると人の手に負えないからね >>877
命令が少ない上に、規則があるから簡単だよ。
それより、2、30人の家の電話番号覚えてた方が驚異的。今はもう絶対無理w Task taskA = Task.Run(async () => {
int count = 60;//6sec
while (count-- > 0) {
Debug.Print("sw0:" + sw.ElapsedMilliseconds.ToString());
await Task.Delay(100);
Debug.Print("sw1:" + sw.ElapsedMilliseconds.ToString());
}
} );
taskA.Wait(5000);
5秒で一旦止まるように見えるが、暫くするとまたタスクは回り始める。C#バグかよ。 しかもUIは5秒間止まってしまう。TASKの意味ないよ。書き方を間違ってるんだろうか？ ちなみUIを止めたくなければtaskAをawaitすれば良いはず >>886-887
何だか良く分からないけど、どうみても6秒以上掛かるコードだし
Wait()はタイムアウトしても終了させないし、待機時間ブロックする
UIスレッドでしたら固まるし、awaitは解放したいスレッドで使う物だよ >>886
思い違い
WaitでGUIのスレッドを使って待機してるのでGUIはその間動かない
5秒たつと待つのをやめてそのまま進む
そのtaskはタイムアウトでは止まる用には設計されてない >>888
上はFormに貼り付けたボタンイベントで実行してるだけ。それなのにボタンを押したら
5秒間フォームが固まる。ｗ 次はasync voidで定義してなくてエラーになる質問が来ると見た >>891
サンプル見て書いたつもりだったが、間違いでしたか？
Asyncが非同期処理を宣言するような機能で、Awaitは解放するスレッドに付けるのだから、Task.Delay(100)を
解放してUIに戻す.つまり100msec待ちながらもUIに制御を戻すってことではないのか？ >>895
UI止めたくなければこうやで
taskA.Wait(5000); ⇨ await taskA; >>895
Taskはスケジューラを指定しない限りワーカースレッドで動くよ
その非同期ラムダでawaitしてもワーカースレッドが解放されてるだけ
UIスレッドで非同期待機するなら作成側を非同期メソッドにしてawaitする await/asyncはネットに碌な例がないからしゃーないわな 間違った理解
awaitがあるとUIに制御を戻す
awaitがあるメソッドに出会うとUIはその場で対象のメソッドの終了を待つ
2番目が特に誤解を招きやすい ＞WaitでGUIのスレッドを使って待機してるのでGUIはその間動かない
＞5秒たつと待つのをやめてそのまま進む
GUIのスレッドを使って待つの当然でしょ。それが目的だから。だめなの？
じゃあどこで待てばいいのだ？
void ボタン_Click(){
TaskAを実行(起動）;
TaskAの完了を待();
}
処理の流れはこうだけど、これは駄目ってこと？ じゃあどうするの？
void ボタン_Click(){
TaskAを実行(起動）;
}
どっか別のところで、例えばタイマー割り込みで
TaskAの完了を待();
ってことか？ 流れがわかり難いので不細工だよな。「シーケンシャルに流れを書いて且つUIが
止まらない」というようになってないと駄目だろ。 ちょっと語弊があるな
間違った理解
awaitがあるとUIに制御を戻す
awaitがついたメソッドに出会うとUIはその場で対象のメソッドの終了を待つ
2番目が特に誤解を招きやすい >>902
やっぱり君か
間違ってるのは自分なのに文句ばかりだな >>902
＞GUIのスレッドを使って待つの当然でしょ
違うね
GUIのスレッドを戻してあげないとGUIは他の仕事ができない winformsで非同期やってた時、デバッグとリリースで動作が違くてはまったなぁ
CheckForIllegalCrossThreadCallsは絶対に許さない >>906
確かそれ挙動は同じなんだけどデバッグ時はIDEかなにかにスレッド渡す奴だっけ？ >>902
いやだから…そのWait()の代わりにawaitをUIメソッドに書くんでしょうが…
そうすれば一旦スレッド制御を返し、Taskが終われば取り戻し再開してくれる
レガシーな書き方だってTaskScheduler.FromCurrentSynchronizationContext()を指定して
ContinueWith()すれば良いし、UIコンテキスト取得しといてワーカースレッドから投げても良い >>908
こいつをTrueにしないと別スレからUI触った時に例外を吐いてくれなかったはず。デバッグで動かしてるか否かで初期設定が変わる。
だいぶ昔だから間違ってたらゴメンね。 ＞Taskはスケジューラを指定しない限りワーカースレッドで動くよ
＞その非同期ラムダでawaitしてもワーカースレッドが解放されてるだけ
＞UIスレッドで非同期待機するなら作成側を非同期メソッドにしてawaitする
言ってることの意味がわからない。Async（）＝＞｛｝にしてるでしょ。
しかもこのラムダはRuｎが確保したスレッドプールで動作してるんでしょ。意味的にそうでないと
可笑しい。でラムダのその中でawaitしてるんだから、、、、って
UIスレでボタン受付
スレ4000でラムダ起動
AWAITでスレ４００１にスイッチして100msec待つ
100msec完了でスレ4000に戻る。
スレ４０００でループ
Task.Wait(3000)はUIスレでスレ4000の終了を待ってる。
ここで待ってる限りUIは止まるってことね。
そういう意味か？ 何となく解った。 まぁ別スレからUI触るなクソ野郎と言われればその通りなので、当時の俺が悪かったのは間違いないのだが。 ＞いやだから…そのWait()の代わりにawaitをUIメソッドに書くんでしょうが…
そういうことね。解り申した。 ちなみに非同期の勉強ならasync/awaitよりも
生threadから始めた方が良いと思うんですが？ あんまり実践で使うことないな
基本的にスレッド必要なときってメソッド内で終わるほど準備ヌルくないし
簡単な機能使って実装すると大抵バグってる ま非同期など定形を何本か覚えたら、ソレ以上凝ったことしても大して効率上がらんのよね たまにはBackgroundWorkerさんのことも・・・
ううん、忘れていいｗ クライアントアプリならイベントハンドラでの await Task.Run だけ覚えてそこから先は全部同期でいい
WebだとTPL Dataflowとか CancellationToken とかまで踏み込んで使いこなさないとあまり意味ないけど >>920
>そこから先は全部同期でいい
は下手に非同期使うと不味いことあるの？ >>921
そもそも勘違いしてるみたいだが、asyncはオーバーヘッドが大きいから一般にはなるべく使わないほうがいい。
じゃあWebではなぜ逆に非同期を全面的に積極的に使うかというと、
多数のリクエストを同時に処理するときのスレッドプールの消費を抑えることでメモリ使用量を低減できるから。
クライアントアプリなんか必ず同時に一人しか使わないんだから、UIのイベントの度にRunしても全く問題にならない。 ＞asyncはオーバーヘッドが大きいから一般にはなるべく使わないほうがいい。
これが独自研究の独自理論 個人的には非同期IOのシナリオの場合ならクライアントでも積極的に非同期使うようにしてるにゃ そもそもなぜ非同期なんかにしたいのか？
すっげー不具合増えそうだしぶっちゃけやるんじゃねーよ
ぶっころ >>926
> 結論 – 非常に短いメソッドにasync/awaitを使うことを避ける、あるいはきついループ内でawaitステートメントを持つことをを避ける
使い所を間違えるなとしか書いて無い。
「一般にはなるべく使わないほうがいい」とか、曲解だよ。 >>930
じゃあ言い換えようか？
複雑になる、オーバーヘッドが増える、それをペイするだけのメリットはない。
GUIをブロックしないという超重大な目的さえ達成できれば十分。 >>920
クライアントアプリならREST API叩くのもごく一般的だと思うが、それも全部同期でやるのかい？ >>932
理解してないのは君だけ
イベントハンドラでだけawait Task.Runしてその中は全部同期でやれって話だぞ var cant = new System.Threading.CancellationTokenSource();//なんじゃこれは？
Task taskA = Task.Run(async () => {
int count = 60;//6sec
while (count-- > 0) {
〜処理
cant.Token.ThrowIfCancellationRequested();//例外発生
}
}, cant.Token );
何じゃらほい？ 大したことできんのにたいそうな名前を付けやがって笑える。普通にflg使ったらいいだけだろ。 >>934
何が面白いのか知らないけど、同期でREST APIを呼ぶケースなんて普通にあるぞ
>>936
正しい非同期メソッドは必ずCancellationTokenを引数として受け取る
そして、非同期メソッドからさらに別の非同期メソッドを呼ぶときには引数にcantを渡す
そうやって共通のCancellationTokenを引き回すことで、別の非同期メソッドを呼んでる間でも待機状態を確実にキャンセルできる
同期ならabortすりゃいいだけだけどね これってどういう意味があるの?単純にフラグを叩けばいいだけだろ。大して利点があるようには思えんが?
ManualResetEventの代わりにflg=Flseで初期化しておいて、setのところでflg=trueにして、
while(!flg);で待機したらいいだけではないのか?
var waitHandle = new ManualResetEvent(false);
Task.Run(() => {Thread.Sleep(2000); waitHandle.Set(); });
Console.WriteLine("Wait");
waitHandle.WaitOne(Timeout.Infinite); 100msecのタイマー割り込みの中でこういうのを順番に実行する。
void timer1(){
switch( state){
case 0:
if( do1() ){state++;}; break;
case 1:
if( do2() ){state++}; break;
case 2:
if( do2() ){state=0}; break;
}
}
何かもっとスマートな書き方はないか？ stateがマジックナンバー感があるので、配列よりDictionaryクラスっても、
でも賛否両論です。 Stateを使いたくない。
while(1){
while(!do1()){ wait(100);}
while(!do2()){ wait(100);}
while(!do3()){ wait(100);}
}
こんな感じでなんかいい書き方は？ >>944
state++;
if(state>2)state=0;
ってやればスマートにならね？ >>947
doの処理ステップによって遅延がでてこない？ >>949
遅延は無視できるレベル。
>>948
ならない。というかStateは使いたくない。 >>944
ネタっぽい質問だけどこんなのでも作るとか
public class RoundRobin
{
int index = 0;
RoundRobin(params Action[] jobs)
{
if (jobs == null || jobs.Length == 0) jobs = new Action[] { () => { } };
this.Jobs = new ReadOnlyCollection<Action>(jobs);
}
public ReadOnlyCollection<Action> Jobs { get; private set; }
public void DoNext()
{
Jobs[index]();
index = ++index % Jobs.Count;
}
}
余談だけど、組み込みか何かの人？
タイマー割り込みてw レス数が950を超えています。1000を超えると書き込みができなくなります。
