ふらっと C#,C♯,C＃（初心者用） Part138

2018/06/05(火) 19:32:42.28

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■関連スレ
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part137
https://mevius.5ch.net/test/read.cgi/tech/1523004019/
■コードを貼る場合は↓を使いましょう。
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: checked:vvvvv:1000:512:----: EXT was configured

2018/06/16(土) 14:42:27.67

>>161
レスありがとうございます。せっかくなのですが、私もその方法はあまり良くないと思います。
ご存知でしたら失礼を許していただきたいのですが、以下の2つの効果は同じではないのです。
async Task X() => Thread.Sleep(1000);
async Task Y() => await Task.Run(() => Thread.Sleep(1000));

>>162
確かに await Task.CompletedTask をどこかに挟むだけなら
変な副作用もなさそうですね。
ただ、警告を抑制するためだけに意味のないコードを加えるのは正しくないように思います。
私がそんなコードを見たら、await Task.Yield() のような効果を期待しているのかなと
誤解してしまいそうです。
（もちろん、 await Task.CompletedTask を勧めてくださっているわけではなく、
　「await を外したくないなら」という無理のある前提に合わせて話してくださっていることは
　理解しています）

2018/06/16(土) 14:59:09.83

これあえて警告出しっぱなしじゃ駄目なのかね
IDEがasyncメソッドをawait無しで実行しているから警告しているだけであって、意図的に同期実行するのならコメントとかで明示しておけば良いような気もするけど

2018/06/16(土) 15:23:38.22

>>164
レスありがとうございます。
たかが警告を消すために実際のコードを書き換える必要があるのかという考えは
実にごもっともだと思います。
ただその場合、警告を抑制するだけでも意図は十分に伝わると思うのですが、
やはり警告はそのままにしてコメントなどで説明を行うべきなのでしょうか。

2018/06/16(土) 15:24:59.98

#pragma warningディレクティブ使って警告を抑止するのが一番素直のような気がする。
知らんけど

っていうか、asyncなしで問題ない前提なら最初から何も悩む必要ないと思うんだけど...

2018/06/16(土) 15:35:00.89

>>166
レスありがとうございます。やはり警告の抑制も選択肢になりますよね。
警告を抑制することに対する考え方は人それぞれということもあると思いますので、
その都度状況に応じた対処法を考えるのが一番でしょうか。

> っていうか、asyncなしで問題ない前提なら最初から何も悩む必要ないと思うんだけど...

申し訳ありません。これについてよく意味が理解できませんでした。
詳しくご説明していただけないでしょうか。

2018/06/16(土) 15:46:13.12

>>167
ごめん後者アホなこと言いましたw

よく考えてみたら、asyncが付くかどうかはただのメソッドの中の実装によって決まる話であって、
ベースクラスやインターフェイスによってそれが強制されることはないよねw

普段深く考えずに使ってることがばれちゃったw

2018/06/16(土) 16:13:25.34

なぜ同期させているのかが根本的に分かって無いから、警告を解く事だけに注意が向いてるんだな。
同期が必要ならコードどころか構造を変えるくらいしないてならないだろうに。

2018/06/16(土) 17:10:20.97

状況把握しきれていないが
async()=>{}という形でラムダにasyncつけることで解決できるケースもあるんじゃね？

2018/06/16(土) 17:13:04.67

>>167
ご説明ありがとうございます。 >>166 で仰っていた意味が理解できました。
async/await は糖衣構文なので確かにベースクラスなどで使用が強制されることはありませんが、
深く考えずに使えるところが糖衣構文のいいところですし、
async を使うメソッドに XxxAsync という名前をつけることが推奨されていることからも、
事実上 async/await を使うかどうかはベースクラスに依存していると言っていいと思います。
これを踏まえて、改めて >>166 にお返事したいと思います。

> っていうか、asyncなしで問題ない前提なら最初から何も悩む必要ないと思うんだけど...

文法上は async なしでも問題ありませんが、コードの一貫性を考えると async を意図した
メソッドのオーバーライドで async なしは問題だと思います。
それにもかかわらず、たまたま実装上 await を全く使わなかっただけで
async の使用をとがめるような警告が表示されてしまうので悩んでいるのです。

>>169
レスありがとうございます。他の方のご意見も聞かせていただいて、
やはりこの警告は不適切で、警告を解くことだけに注意を向ければいいように感じてきています。
それに対して異論を唱えてくださっているようなのですが、勉強不足で仰っていることが
よく理解できていないので、申し訳ないのですが詳しく説明していただけないでしょうか。

2018/06/16(土) 17:18:42.84

>>170
レスどうもありがとうございます。
このような返しばかりで情けないのですが、理解力が足りず仰っていることがよくわかりませんでした。
申し訳ありませんが詳しいご説明をお願いできないでしょうか。

2018/06/16(土) 18:03:54.76

先ず、同期と非同期で何が違うのか、
同期は目的の処理を完了して戻って来る事が大前提で作られている。
非同期は目的の処理を行う指示だけをして戻って来る。
だから戻り値も自ずと意味が違って来るのが普通。
同期の戻り値は実行結果、非同期の戻り値は指示出来たかどうかで結果はまだ分からない。
そこを根本的に間違えているから、問題なんだよ。

2018/06/16(土) 18:08:04.04

>>173
基底クラスやインターフェイスに合わせるためであったり、
後でDB使った実装に変更する予定で今はハードコードしておくみたいなときには普通にあるケースだよ
後で非同期に変えるのは影響が大きいからね

2018/06/16(土) 21:30:40.09

>>173
レスどうもありがとうございます。
同期処理と非同期処理の違いは、一般論としてはおっしゃるとおりだと思うのですが、
それが >>174 でご指摘いただいているような目的を達成する上で障害になっていて、
そのような問題を解消するために async/await 構文が作られたのではないでしょうか。
だとすると、同期処理と非同期処理の違いを理由に await なしの async を
否定することは本末転倒のように感じてしまうのですがいかがでしょうか。

>>174
ご説明どうもありがとうございます。
具体例を含めてとてもわかりやすく感じたのでこのレスの前半で引用させていただきました。
私にはこれだけ要領よく説明することはできそうにないので助かりました。

2018/06/16(土) 21:44:52.43

まあ、メイン処理止めていいなら待てばいいじゃない。
止めたく無いならポーリングやコールバックで終わったの知ればいいじゃない。
コーディングでワーニング出るから構造を弄るって手法そのものが間違いって言ってるの。

2018/06/16(土) 22:10:42.86

>>176
メイン処理を止めたくないならポーリングやコールバックを明示的に記述する以外に
選択肢がないというように読めてしまったのですが、この部分に間違いはないでしょうか。
もしそうなら async/await 構文についてあまりお詳しくないようにお見受けしますので、
よろしければ一度お触りになってみてください。
非同期処理の大変さをご存知であればこそ、便利さを実感できるのではないかと思います。

（ちなみに、今の問題は非同期処理を行うことも可能なメソッドをオーバーライドする際に
　非同期処理を全く使わないと警告が出てしまうということですので、
　何かに妥協してメイン処理を止めるというわけではありません）

2018/06/17(日) 00:16:30.35

そもそもasync修飾子そのものには、たんにawaitする目印としての意味しかないわけで
awaitしないメソッドをasyncにするのが根本的におかしいとしか思えんのだが

2018/06/17(日) 04:27:25.92

wpfのフォームってhtmlとcssが合わさったようなもん？

2018/06/17(日) 05:09:52.71

>>178
async Task Hoge() { }
↑は警告は出るもののコンパイルできますが
Task Fuga() { }
↑はコンパイルすらできないので、async がたんに awaitするための目印というのは語弊があるのではないでしょうか。

2018/06/17(日) 10:24:51.50

> async を使うメソッドに XxxAsync という名前をつけることが推奨されていることからも、
> 事実上 async/await を使うかどうかはベースクラスに依存していると言っていいと思います。

TAPはTaskを返す関数の実装にasync/awaitを強要せんし使う側も関知せんじゃろ
AsyncサフィックスなんてそれこそEAPの頃からの慣例でしかない

awaitを使わず何故か付いてるasyncよりTask.CompletedTaskを返すコードの方がよほど明確だと思うがね

2018/06/17(日) 11:46:32.45

>>180
ただの目印と理解していいよ
asyncって目印を見つけたらメソッド内だけ文法をちょっと変えますねっていう取り決めなの

目印もなしに勝手に文法を変えられたら仕事にならん
だから目印が必要なの

目印を付けただけでエラーになると言うけど
目印を付けたら文法が変わるのだから同じコードでエラーが出たってなにもおかしくないだろう？

2018/06/17(日) 12:14:10.68

>>181
レスどうもありがとうございます。

async Task SayHello3() { await SayHello(); await SayHello(); await SayHello(); }
async Task SayHello2() { await SayHello(); await SayHello(); }
async Task SayHello1() { await SayHello(); }

は問題ないのに

async Task SayHello0() { }

ではなく

Task SayHello0() { return Task.CompletedTask; }

と書かなければならないことに不自然さを感じていたのですが、
2つ目の SayHello0() を単独で見れば、おっしゃる通り何をしているかは明確ですし、
async に固執するのもあまり良くなさそうですね。

async はそのままにして警告を抑制する方法を提案してくださる方もいらっしゃいますし
私としてもそちらの選択肢を完全に切り捨てるまでの確信は持てていないのですが、
Task.CompletedTask を返す方法も決して悪いものではないと分かりとても勉強になりました。

>>182
確かにそのとおりですね。失礼いたしました。
ただ問題なのは、「目印を付けただけでエラーになる」のではなく、
「目印を付けないとエラーになるのに目印を付けても警告が残る」という点でして、
せっかくの目印の機能を気持ちよく使うことができず、どうしたものかと考えております。

2018/06/17(日) 12:46:14.26

結局質問者の疑問はこういうこと？

(1) サブクラスで非同期メソッドとして実装される可能性があるメソッドの名前は
Asyncでサフィックスすべきか？

(2) (1)がYesの場合、そのメソッドが非同期で実装されなくても（awaitを含まなくても）
asyncで修飾すべきか？

正解はYes-No？
理由は、非同期メソッドは使う側がそれを非同期メソッドだと理解している必要があるのに対し、
非同期メソッドじゃないものを非同期メソッドと誤認しても弊害はないから

もちろん不要な混乱を避けるために、「このメソッドは多態の都合上Asyncでサフィックスされてるけど
非同期メソッドじゃないよ」みたいなコメントは必要か？

2018/06/17(日) 13:22:22.85

>>184
整理していただきどうもありがとうございます。

(1) については実は疑問であるという認識をもっていたわけではなく、
ご指摘をいただくまで当然そうするべき事柄であると考えておりました。

(2) がまさに疑問点でして、(1) が Yes/No のどちらであっても
答えが得られると嬉しいと思っています。

> 非同期メソッドは使う側がそれを非同期メソッドだと理解している必要があるのに対し、
> 非同期メソッドじゃないものを非同期メソッドと誤認しても弊害はない

おっしゃる通りだと思います。（もちろん細かなオーバーヘッドが問題にならない場合の話ですが）

> 「このメソッドは多態の都合上Asyncでサフィックスされてるけど
> 非同期メソッドじゃないよ」みたいなコメントは必要か？

インターフェース等を介さずにメソッドを呼び出す可能性がある場合は
そのようなコメントがあると親切だと思いますが、
私としては、必ずしも必要ではないように思います。

2018/06/17(日) 14:33:41.38

>>183
気持ち良い悪いみたいな感覚の話にすると結論が出なくなる

・コードに統一感があったほうが気持ちがいい(俺はこの感覚がよくわからんが)
・使ってないものを使いますと宣言するのは気持ちが悪い

どっちも言い分としては間違いではないしどちらがより正しいかとも言えない
それは見た人によるとしか言えない
君が美しいと思って書いた統一感のあるコードは、俺からすれば必要のない無駄な記述の多い汚いコードに見えるかもしれない

それはさておき
asyncメソッドはTaskインスタンスの生成とスレッドの生成に繋がる可能性がある
インスタンスの生成はともかくスレッドを無駄に消費するってことはOS全体に負荷をかけることにも繋がりかねないので意味がないなら避けるべきだ
しかし文法上の間違いではないのでエラーと断言することもできない
間をとって警告を出すってのが妥当な落とし所じゃないかな

2018/06/17(日) 21:01:18.97

・スレッド生成
勉強してから言えよって思う

2018/06/17(日) 21:08:29.24

あーこれゴミクズにありがちな燃えるコメントの仕方だわ
言い争いが始まるので、賢明な諸兄は3日ほどスレを閉じておくのがよろしい

2018/06/17(日) 21:15:10.69

静的メソッドの中で動的メソッドって呼び出せないってあるけど、自分のクラスのインスタンスのメソッドは呼び出せるの？教えて雑魚

2018/06/17(日) 21:27:50.40

> async Task SayHello3() { await SayHello(); await SayHello(); await SayHello(); }
> async Task SayHello2() { await SayHello(); await SayHello(); }
> async Task SayHello1() { await SayHello(); }

と書くより引数nで実行回数を渡してforループで制御したらいい
n=0でasync awaiｔのペアがあるにかかわらず一度も実行されないawaitのついたメソッドができる
勿論警告もでないし誰かの言う一貫性のある美しいコードじゃないか

2018/06/17(日) 21:32:42.49

わかってると思うけどawaitがついたメソッドに突入した時点で
内部が自動的に別のスレッドで実行されるわけじゃない
中に入っても最終的にタスクにたどり着かないと別スレッドはスタートしない

System.Threading.Thread.CurrentThread.ManagedThreadIdでスレッドIDがでるから確認したらいい

2018/06/17(日) 21:38:25.64

>>191
await後に書いた処理って元のスレッドに同期されると思ってたけど、awaitで実行されたスレッドのまま進むよね？
Formアプリであれ？invokeしなくていいの？って思った記憶ある。思い違いだったらすまぬ

2018/06/17(日) 21:42:03.70

非同期自体が複雑だし、(当時は)新しい構文ってことで、混乱を少しでも減らすために警告にしてるだけっぽいね
抑止しちゃっていいと思うよ

2018/06/17(日) 22:13:20.40

>>193
Formが作成された所謂UIスレッドでは同期されるが、コンソールアプリ等では同期されない

もうちょい突っ込むと、await文が実行されるスレッドにSynchronizationContextへの仕込みがあるかどうかで違ってくる
await後に実行されるスレッドはSynchronizationContext.Postの実装により決定される

Winformsは最初のフォーム作成時にWindowsFormsSynchronizationContextを現在のスレッドに設定し
WindowsFormsSynchronizationContext.Postはメッセージループを仲介してUIスレッドでawaitの続きを実行する

具体的な実装はReference SourceやmonoのWindowsFormsSynchronizationContextを読むのが良い

**194** (ﾜｯﾁｮｲ edd3-Bw3Y) · 2018/06/17(日) 22:18:16.07

安価まちげーた>>192

なんかテキトーに書いたら分かりにくいな・・・
要はWinforms（WPFも同様）のスレッドでawaitするとその後の文は裏で勝手にControl.Invokeされてると思えばええねん

2018/06/18(月) 03:16:27.74

>>180
>Task Fuga() { } はコンパイルすらできない
それは戻り値のチェックで、int Fuga...でもコンパイルできないだろ
Taskもasync/awaitも関係ない話

むしろ、async Task Hoge() { } がタスク戻さないのにコンパイル通ることのほうが問題じゃね
つかほんとにこれ警告だけで通って正常に動くの？
そのときHoge()で何が帰ってきてるんだ？

2018/06/18(月) 03:36:27.38

まあその例で統一したやり方でやりたいなら
async Task SayHello0() { await Task.CompletedTask; }
で良いんじゃないのか

2018/06/18(月) 07:05:52.53

>>196
最適化してCompletedTaskでも返すのかなとも思ったけど
IL見ると他と同じようにコード生成して実行してんね
このオーバーヘッドが必要な処理なら警告を無視してasync使えばいいと思う

2018/06/18(月) 10:59:47.44

どう考えても質問者の方がよく分かってるのに
何も分かってない奴に限って上から目線で偉そうに何か言ってるのは滑稽過ぎるねw

気付いてないのは本人だけ（とすら気づいてない）のも何とも笑いを誘う

2018/06/18(月) 11:33:39.78

質問者のドメイン知識の話だろ。

質問者以外に、このスレどんなエスパーいるのか？

2018/06/18(月) 12:52:58.18

実際にawaitされることで呼び出し側が想定されることが実現されるなら
たとえ何もしない無駄なスレッドを使用したとしてもそれが一番いい
最適化されて何もしないとなればUIスレッドなどの副作用を期待していた呼び出し側が困る
実際はそういうことはおこらないので問題ない

上に書いてあったawait Task.CompletedTask;が一番いい答えだと思う

2018/06/18(月) 17:06:03.17

プログラミングってさあ、基本を使い倒すほうがいいの？

2018/06/18(月) 18:38:53.61

皆さんレスどうもありがとうございます。

>>186
スレッド生成はともかく、無駄をなくすという観点は重要ですね。
>>198 に書いていただいてあることも踏まえると、
> しかし文法上の間違いではないのでエラーと断言することもできない
> 間をとって警告を出すってのが妥当な落とし所じゃないかな
というご意見は実に的を射たものであるように感じました。

>>190
> forループで制御したらいい
同じメソッドを繰り返し呼ぶ例は不適切でしたね。失礼いたしました。
ただ、for ループ版に n = 0 を渡しても何の問題もないのに
async Task SayHello0() { } では警告が出るというのも
やはり腑に落ちない感じがします。

>> 191
> 中に入っても最終的にタスクにたどり着かないと別スレッドはスタートしない
やはりそこが重要なポイントですよね。
だからこそ、最終的にタスクにたどり着かない選択肢がある方が
自然だと思うのですがいかがでしょうか。

>>193
> 非同期自体が複雑だし、(当時は)新しい構文ってことで、混乱を少しでも減らすために警告にしてるだけっぽいね
> 抑止しちゃっていいと思うよ
言われてみると、構文に不慣れな方向けの警告であるという考えは
とても納得ができました。
あとは、「自分は構文を十分に理解しているから警告を抑制しても構わないのだ」
という主張をいかにして人様に受け入れて貰うかが課題でしょうか（汗

2018/06/18(月) 18:39:23.10

>>196
> むしろ、async Task Hoge() { } がタスク戻さないのにコンパイル通ることのほうが問題じゃね
> つかほんとにこれ警告だけで通って正常に動くの？
> そのときHoge()で何が帰ってきてるんだ？
確かに一見すると不思議ですよね。
このあたりの詳しい話は TaskAwaiter で検索するとお知りいただけると思います。

>>197 >>201
> await Task.CompletedTask
>>162 に書いていただいていることを仰っているのだと思いますが、
>>162 は >>161 の方法の不味さを説明するために await Task.CompletedTask を
引き合いに出されただけで、実際にこの方法を推奨されているわけではないと思います。
私自身も、async Task Hoge() { } と Task Hoge() => Task.CompletedTask; は
それぞれメリットがあるのに対して sync Task Hoge() => await Task.CompletedTask; は
すべての面で上 2 つに劣っていると考えておりますが、いかがでしょうか。

>>198
> 最適化してCompletedTaskでも返すのかなとも思ったけど
> IL見ると他と同じようにコード生成して実行してんね
大変ためになる情報をどうもありがとうございます。
私も確認してみましたが、async Task Hoge() { } と
Task Hoge() => Task.CompletedTask; との間にこれだけ IL のコードに差があると
前者を使うのは躊躇してしまいますね。そもそも私は
> このオーバーヘッドが必要な処理
になる状況が分からず、CompletedTask を返すように最適化が行われるべきだと思うのですが、
「await なしの async」と「CompletedTask 返し」との間の違いに気づいていらっしゃるようであれば
ぜひお教えいただけないでしょうか。

2018/06/18(月) 18:46:20.98

>>202
何が聞きたい

旅行ってさあ
車で行ったほうがいいの？
→目的地や条件による

2018/06/18(月) 20:44:23.89

>>202が一を聞いて十を知る頭の良い人間なら先に一通り言語をマスターした方が効率的
そうでないなら最初から高度な機能を覚えてもそれが何の役に立つのか理解できないから、まずは基本だけで身をもって苦労したほうがいい

2018/06/19(火) 05:31:43.83

>>204
そもそもawait なしの asyncが必要な理由も場面も思い浮かばんが
自分一人でやってるなら好きにすればいいんじゃね

最適化うんぬんを言うなら、Taskを返すどころかそんな呼び出しそのものが不要じゃね

2018/06/19(火) 08:14:05.91

そもそものそもそもasyncやawaitで気軽にスレッドを立ててるような処理はだいたいバグってる
スレッドを立てるってそれ自体の処理より
立てても大丈夫なぐらいの前準備のが遥かに手間がかかる
気軽に立ててあるとこはまず間違いなくバグってるので安心していい

2018/06/19(火) 08:47:25.71

asyncとスレッドって直接関係ないだろ
スレッドは非同期処理を実装する手段の一つに過ぎない
最近のazureなんか「上司にメール送って添付URLのページにある承認ボタンが押されるまで待つ」みたいな非同期処理ですらawaitできるんだぞw

2018/06/19(火) 10:49:26.69

誰に向かって説教してるつもりなのかねw
馬鹿過ぎる

**デフォルトの名無しさん** (JP 0H49-B+cT) · 2018/06/19(火) 17:36:20.33

google検索で
@it async await
これ読んでわかった気になった。
シンプルな実装では使えたけど、応用でつまずく。最近プログラム組んでないので頭固い……

2018/06/19(火) 17:40:54.18

固ければジューサーに入れてみる？

2018/06/19(火) 18:44:23.63

普通のジューサーでは>>211の固い頭は砕けません
そこでショップジャ〇ンのマジックブレッドデラックスを使えば楽チンに下ごしらえができます

2018/06/19(火) 19:56:40.35

C♯を勉強するのにおすすめのサイトありますか？
何かを作りなが勉強したいなと思ってるんですが。

2018/06/19(火) 20:10:42.40

>>214
https://dobon.net/vb/dotnet/index.html
http://www.atmarkit.co.jp/fdotnet/csharp_abc/index/
http://ufcpp.net/
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/
ここで勉強するというかやりたいことを「C#」に続けてググるとだいたいこのあたりがヒットする

2018/06/19(火) 20:12:26.56

>>213
そこで、トゥルースリーパーとパチもんハズキルーペ買った。
パチもんの方はメガネにLEDライトが付いてたからつい。薄暗いとこであれはめちゃ便利（稀にしか使わないけど…orz）。（100金の老眼鏡でいいと思う。しょせん凸レンズの一種だから。）
トゥルースリーパーは半年くらいたってまだ箱の中orz

2018/06/19(火) 21:01:02.40

c#のコーティング方法で検索すること多いけど、なぜかLINQで解説しているサイトがほとんどない
日本語サイトも海外サイトも

なんで？

2018/06/19(火) 21:02:44.86

>>217
実践的なアプリ開発で使われる機能だから、コピペTips系サイトのサンプルコードで必要になることはほとんど無い

2018/06/19(火) 21:53:01.39

素人に使われると価値が下がるからね
素人は年収300万で死ぬまでくだらないコードを書いていればいいんだよ

2018/06/19(火) 22:04:52.94

>>217
ほとんどないわけねーよｗｗｗ

2018/06/19(火) 22:16:45.72

>>217
LINQは手段であって目的じゃないからじゃないかなああああ

2018/06/20(水) 09:42:33.52

FileSystemWatcherのChangedイベントの発生条件は、監視しているディレクトリ内のファイルまたはディレクトリのサイズ、システム属性、最後の書き込み時刻、最後のアクセス時刻、またはセキュリティアクセス許可の変更のようですが、
このうちのどれが変更されたか種痘するにはどうすればよいでしょうか？

2018/06/20(水) 11:51:07.40

>>218
そういうもんなの？

>>220
スタックオーバーでたまに外人さんがLINQで答えてるのあるくらい
割合的に3％くらいな印象

みんな使わないんだね

>>221
手段でも目的でもどっちでもいいの

2018/06/20(水) 12:05:31.86

>>222
使ったことないけど、イベントハンドラで受け取れる引数（FileSystemEventArgs）
で普通に分かるんじゃなくって？
https://msdn.microsoft.com/ja-jp/library/system.io.filesystemeventargs.aspx

2018/06/20(水) 12:06:45.48

>>222
あらかじめ情報をどこかに持っておいて比較するしかないかな

>>224
変ったという情報しかくれない

2018/06/20(水) 12:14:29.61

>>225
いやいや、ちゃんと提示したリンクよく先見ました？

2018/06/20(水) 12:16:40.94

>>225
あー失礼。
よく見ると結局詳細な情報は得られないみたいね

2018/06/20(水) 12:22:49.35

ちょっとググって見た感じ、結構面倒だけど、
知りたい変更の数だけ適切にNotifyFilterプロパティを設定したFileSystemWatcherを作れば
一応可能な感じはするね

2018/06/20(水) 12:29:31.18

>>223
みんな使ってるよ

2018/06/20(水) 22:31:23.62

ググり方を知らない典型

2018/06/21(木) 21:35:06.03

エクセルbook1を開かずにsheet2の2列目に入ってる項目をコンボボックスに入れたいのですが、どうやるんですか？

2018/06/21(木) 21:41:20.00

中身を見ずに言い当てる手品のやり方なんか知らねーよ。

2018/06/21(木) 21:43:13.77

地獄に落ちろ

2018/06/21(木) 21:51:22.49

Excel.exe使わずにって意味ならいくらでもあるだろ

2018/06/21(木) 22:32:53.55

御託はいいから答えろゴミクズ

2018/06/21(木) 23:11:39.87

xlsxならclosedxmlつかえば

2018/06/22(金) 00:26:01.32

ファイル開かずにならもちろん無理。
見えないだけなら可視しなければいいだけやん。

2018/06/22(金) 00:49:53.36

日本人のエクセルスキーは異常
海外にも神エクセルってあるんだろうか

2018/06/22(金) 01:45:41.77

>>231
コンボボックスとは？

2018/06/22(金) 03:12:37.07

どんなものを作ればいいのかわからない
何をつくればいいんだ
教えてお前↓

2018/06/22(金) 03:21:00.63

JavaMachine

2018/06/22(金) 06:50:27.01

会社が未だにxpが数台あって、数多くあるエクセルを開いて処理して閉じる開いて処理して閉じるってやると重いけどなんか早くなる方法ってある？
database？SQL？
VB6でそうやってエクセルファイルを扱って処理してるんだけど

2018/06/22(金) 06:57:20.38

5万円のPCを買ってくる

2018/06/22(金) 07:07:33.30

>>238
外人はそもそも罫線をあまり使わない
方眼紙に文字を詰め込むのは日本猿特有の習性

2018/06/22(金) 07:09:51.33

私は猿なのでVSの枠がはっきりしないフラットデザインが馴染めません。

2018/06/22(金) 07:20:32.82

日本猿も江戸時代はプレーンテキストだったのに、どこで間違えたんだろうな

2018/06/22(金) 09:37:09.99

>>231
開かないとわかりません

2018/06/22(金) 09:59:49.98

>>245
同意
各項目の意味付けが曖昧になってすごく見づらい。退化と言いたいくらい。
そのうち立体的にするとわかりやすいやろって波が来ると思う。

2018/06/22(金) 10:09:55.10

そもそも細々としたアイコンやメニューを大量に配置するのに適したUIではないわ
Azureコンソールとか見てても思うけど、マイクロソフトにUXデザイナーがいないってのは恐らく本当

2018/06/22(金) 10:13:34.27

VSCodeのUIは使いやすいけどな
本家VSもボタン全部無くしてコマンドにするべきだわ

2018/06/22(金) 10:18:33.53

web service(asmx)について教えてください。
利用する複数のアプリで使い回したいものをstatic変数に保持したいのですが、寿命が尽きるタイミングは分からないでしょうか？
具体的にはデータベースのconnectionでして、セッションをケチるために1つだけを使い回そうと考えています。寿命が尽きる時にdisposeしたいのですが、できない場合問題でしょうか？

2018/06/22(金) 10:26:12.51

C#の設計思想とか、どういう設計でコード書いたらいいかみたいなのがわかりやすい書籍ってある？

2018/06/22(金) 10:51:01.98

>>244
値を縦に並べて合計との間に一本横線引いてあるだけとか、海外の資料じゃ良くあるよね

>>245
馴染めないという程じゃないけど、もうちょっと境界をはっきりして欲しいな
Windowsのデザインからしても最近のMSのトレンドなんだろうけど

2018/06/22(金) 12:00:58.68

>>252
c#実践開発手法がいいと思う
設計する上で重要な思想が学べるはず

2018/06/22(金) 12:11:16.45

フラットデザインは最近はやりのユニバーサルデザインとは真逆

2018/06/22(金) 12:11:51.14

>>254
よさげ
とりあえずKindle版ぽちった。
ありがとう！

2018/06/22(金) 12:19:03.29

第2版が出てたんだな
ステマか

2018/06/22(金) 14:40:02.21

ダイレクトやろ

2018/06/22(金) 17:59:11.25

むしろサードパーティマーケティング

2018/06/22(金) 18:01:56.90

今年独り社内SEとして入社しC#を選んだ者ですが、コンストラクタをオーバーロードして引数が有るものと無いものを作りました

よくよく考えると引数が無いコンストラクタのインスタンスを作って引数有りを前提にしたメソッドをコールすると最悪例外を出してしまうのですが、これは設計不良として検討し直しでしょうか?よくある事として許容されるでしょうか?

2018/06/22(金) 18:07:20.69

>>260
>引数が無いコンストラクタのインスタンスを作って(コンストラクタの)引数有りを前提にしたメソッド
人に聞くまでもなく作り直さないとだめだろう

**260** (ﾊﾞｯﾄﾝｷﾝ MM33-+a6w) · 2018/06/22(金) 18:21:23.38

やっぱり設計の問題ですよね
フィールドに初期値入れれば例外は起きないと思いますが、引数必須のインスタンスを作られたら無意味なメソッドが完成するというのは設計者失格ですよね