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

2019/05/16(木) 19:28:06.27

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

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

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

■関連スレ
C#, C♯, C＃相談室 Part93
http://mevius.5ch.net/test/read.cgi/tech/1492818720/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part142
https://mevius.5ch.net/test/read.cgi/tech/1551908141/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
-
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2019/06/10(月) 19:50:13.10

>>380
https://docs.microsoft.com/ja-jp/dotnet/framework/winforms/controls/disable-buttons-in-a-button-column-in-the-datagrid

2019/06/10(月) 19:52:29.65

>>381
テストまでいってねっつのアホなん？

2019/06/10(月) 19:55:32.78

抽象化されたソースから追えないゴミカスコードをどうやってコピペしたらいいですか？

インターフェース同じやつ片っ端から貼りまくればいいですか？
36っこありますね
→ウンコですね New!

2019/06/10(月) 19:59:23.27

コピペできないって悩むってことはやっぱり抽象化が正解なのか
いかに下っ端コーダーにコピペをさせないかがプロジェクト成功の鍵だからな

2019/06/10(月) 20:07:55.28

>>385
バカじゃん
まるごとコピペして名前だけ変えて放置だっつの
こんなキタネェコード付き合ってらんねーよ
1クラス1ファイルで書いてあるけどこんなゴミにこんなファイル数いらねーよ
Xxx.csに全部ツッコんでやった
まとめてゴミ箱だｗ
アンチパターン「マトリョーシカ」「たけのこの皮」「玉ねぎの皮」「マズイミルフィーユ」とか名付けたい
くだんねー薄皮クラス全部いんねっつーの

2019/06/10(月) 20:09:50.35

>>386
はいリジェクト
ばいばい

2019/06/10(月) 20:37:44.89

逃げたか

2019/06/10(月) 22:36:29.43

>>382
そこまでしないと実装できないんですね。
Enabled=False
でできればよかったのですが、うーんどうしよう。

**デフォルトの名無しさん** (ｽﾌｯ Sdd7-tCrF) · 2019/06/10(月) 23:01:39.91

>>389
サンプルの
DataGridViewDisableButtonCell
をコピペで持ってきたらいいだけじゃん

2019/06/10(月) 23:28:43.62

でも正直なんでこんな面倒臭いの？ってぐらい作ったやつのセンスが悪いよね

2019/06/10(月) 23:40:05.50

C#は Visual Studio のサポート機能が無いと、コード書ける気しないわな。

2019/06/10(月) 23:57:56.14

>>390
それすら面倒だけどやってみます。

MSが普通にEnable実装しておけば、俺たちは True Falseの設定だけでできたのに。

2019/06/10(月) 23:58:17.24

>>392
最近よくVisual Studio Codeで書いてるよ

2019/06/11(火) 00:20:18.49

>>393
お前が何を必要としてるかまでMSは知らないから仕方なくね

2019/06/11(火) 00:27:16.57

WinFormsのコントロール全般だけど、MSとしては>>390程度のことは
自前で継承して作り込んで使ってくれっていうスタンスだからなあ
（MSDNのドキュメントもそれ前提の書かれ方だし）
作りこむのが面倒であればGrapeCityとかが売ってる高機能なコンポーネントを使えばいいわけだし

2019/06/11(火) 00:29:30.86

>>395
ちょっとでも使われ方の検討したのかよ
ってレベルじゃね？これ

2019/06/11(火) 01:03:45.60

>>395
そういう問題じゃなくて、ボタンにEnable False True入れるなんて常識だろ。
それ位実装しとけよ。くそMSって話。

2019/06/11(火) 01:12:02.27

>>398
こいつWebアプリ開発させられたら発狂しそう

2019/06/11(火) 01:38:08.73

今日のNGはこれか
VMcLTapW0
真っ赤にして待ってろ

2019/06/11(火) 01:45:34.19

なんか普通のことが普通にできなくなって開発者からそっぽ向かれてない？

wpfなんかこんなののオンパレードだし俺ら工場のおっさん向けアプリ作ってるだけなんに
必要のない変な機能多すぎ
その割にこんな簡単な機能は未実装って
未完成ってレベルじゃないよね

2019/06/11(火) 01:48:32.42

>>401
そんなに同意して欲しいなら同意してやるからもう寝なよ

2019/06/11(火) 01:51:14.95

>>402
むしろお前こそ言いたいことがあるならハッキリ言うべき
無言でユーザだけ減ってる状態に苦労してると思うぞmsは

**デフォルトの名無しさん** (ｽﾌｯ Sd2f-tCrF) · 2019/06/11(火) 02:17:35.18

>>403
言いたいことはお前が無能ってことだよ

2019/06/11(火) 02:19:21.88

お前みたいな馬鹿が尻の穴嘗めてくれるからウハウハだぞバカ

2019/06/11(火) 02:28:30.43

多分、日本はwindowsで作った資産があるけど
そうでない国はお金がないからわざわざWindowsを使わない
そんな状態が続いたもんだからlinuxの資産が貯まってしまって
お金を持っても今度はWindowsには移行できない
そんな事情のある最近のlinuxに寄り添ってる理由だろ
昔はその作りやすさから王者だったけど
最近そーでもねーのが致命的になってんじゃねーのか？と

2019/06/11(火) 02:33:30.92

クソ長文書いてねえで寝ろクズ

2019/06/11(火) 03:14:41.06

HTML のボタンには、disabled 属性もある

2019/06/11(火) 07:09:30.30

もうwebオンリーで行くかなと思ったけどバーコード使いたいと言われるとFormeアプリ使わんとダメだよね
XAMLは流行る予感がしないから触る事ないな

2019/06/11(火) 08:52:13.44

Webでバーコード扱えるけど

**デフォルトの名無しさん** (ｽﾌｯ Sdd7-aKta) · 2019/06/11(火) 10:34:45.11

Shape Detection APIな。
PCのChromeでも動けば動作検証楽なのになぁ、あれ。

2019/06/11(火) 14:05:54.20

リーダーをUSBに差せばWebでも使えるやで

2019/06/11(火) 14:08:24.54

ふぅーDataGridViewのボタンの非活性できた。

MSはその程度実装しておけよ

2019/06/11(火) 14:27:25.63

CheckBox も同様だけど、Visible と Enable くらいは実装しとけよ、って思うよなぁ
WinForms に対しては全くやる気ないみたいだけど

2019/06/11(火) 14:41:17.27

>>414
実装もそこまで時間かかるとは思えないんだよな
なんか詰めが甘いというか・・・

しかもVS２０１７になっても未実装って

2019/06/11(火) 15:25:57.49

x64 のときは Form_Load の中での例外はスルーするバグも絶賛放置
（x86 だったら、ちゃんと例外を捕捉する）

2019/06/11(火) 15:57:17.26

Windows Formなんてとっくに見捨てられてるからね。メンテナンスフェーズかも知れん。WPFですら10年前だし。ということでUPF使え。
…ってMSは思ってるかもだが、Formなにかと楽なんだよなあ

2019/06/11(火) 16:23:20.80

俺がゲイツなら首にするわ

2019/06/11(火) 18:42:14.00

.NET Core3.0リリース後にちゃちゃっとPR書けば？そんなに簡単なら

2019/06/11(火) 20:32:19.05

悪いけど、FullFx版のWinFormsとの互換性を損なうようなコミットは全部リジェクトだと思うよ
forkして弄るのは勝手だけど

2019/06/11(火) 20:58:05.88

>>420
.NET Core3.0後にどうなるかはまだ不透明
現状はそうだけどね

2019/06/11(火) 21:10:59.72

どのみちMS自身が今後WinFormsに機能追加をすることはありえないんだから、縛りのきつい公式リポジトリに拘る意味がないでしょ
WinFormsをクロスプラットフォーム化するコミュニティプロジェクトは必ず立ち上がるから、それに参加したらいい

2019/06/11(火) 21:15:40.32

>>422
WinFormsのクソな部分がそのまま移植されるとは思わないから別物になると思う

汎用的な部分だけ移植なら整合性が合わなくなるからそもそも新しいの作るだろ

2019/06/11(火) 21:40:49.66

>>423
残念ながらベタ移植だよ
ほとんどのソースはオリジナルからコピーしてきてヘッダコメントを変えただけ
WinFormsをCoreでビルドできるように手直ししただけの代物だ
WPFなんかC++/CLIにべったり依存してるからもっと酷くて、
WPFをビルドするためだけにVCのコンパイラに限定的なCoreサポートを追加して無理矢理ビルドしてる
そんな不毛なことするくらいならネイティブ部分を書き直せと批判されてしばしばissueが炎上してるが、MSはガン無視

2019/06/12(水) 09:44:54.85

DataGridView_hoge.AllowUserToResizeColumns = false;

列幅変更出来ない様にしたつもりですが、普通にドラッグしてサイズ変更出来てしまいます。
何が原因でしょうか？？？

2019/06/12(水) 10:24:07.46

行ヘッダ列はAllowUserToResizeColumnsじゃなくてRowHeadersWidthSizeModeで設定しないといけないけど
それ以外の列ってことなら何か変なことやってるんじゃないのとしか言えないなぁ

2019/06/12(水) 10:29:24.57

>>426
RowHeadersWidthSizeMode
ためしてみます。

2019/06/12(水) 21:10:32.82

なんかWindowsアップデートで動かなくなったりするから
Windowsやめようぜって方向になってるぞ

2019/06/12(水) 21:27:03.90

どうぞ

2019/06/12(水) 23:03:21.43

どうぞどうぞ

**デフォルトの名無しさん** (ｽﾌｯ Sdd7-tCrF) · 2019/06/12(水) 23:30:47.47

バイバーイ(^.^)/~~~

2019/06/13(木) 12:45:58.94

WPFの将来性ってどうですか？
今から勉強する価値ありますかね

2019/06/13(木) 15:02:14.86

>>432
将来性はない
勉強する価値もない

2019/06/13(木) 17:22:47.41

たぶん現状のまま放置されるって意味では将来性ないけど
Silverlightみたいに事実上使えなくなることは恐らくないから
勉強して無駄になることもないと思うよ

そいうや、何年か前にWin32を廃止する計画を読んだ記憶があるけど
例によって軌道に乗ってるように思えんねw

2019/06/13(木) 18:14:02.25

>>434
win32廃止したら、Windowsじゃ無くなるじゃん

**デフォルトの名無しさん** (ｽﾌｯ Sdba-UiF5) · 2019/06/13(木) 22:23:06.18

>>435
win64 APIのみにするってことでしょ

2019/06/13(木) 22:27:30.58

ARM使い「そうか」

2019/06/14(金) 09:46:05.42

>>436
Windowsから互換性取ったらMacとの優位性が崩れてしまうわ。

2019/06/14(金) 10:19:55.42

う互換性

2019/06/14(金) 13:28:36.75

GDIとかいつまで残ってんだろ

2019/06/14(金) 13:36:31.53

APIとしてはWindowsがある限り残るだろ
内部的に別の仕組みの描画フレームワークに渡すだけになる将来はあるかもしれんが

2019/06/14(金) 19:05:00.84

独自OSはやめてLinux M$ディストリになったら最高なんだけどね

2019/06/15(土) 00:33:09.29

while(i<=1000000)
{
i++;
}

こういうお手製のループって結局invokeと同じ機能なんですかね？
待つという意味では

2019/06/15(土) 02:59:58.42

質問です。
JSONシリアライズなんですけど
{ "foo": "bar" }
としたいのに、DataContractJsonSerializerに
Dictionaryをシリアライズさせると
{ "key": "foo", "value":"bar" }
となってしまいます。
何かいい方法ないですか？
どういうキーワードでググればいいかも分からなくて。

2019/06/15(土) 06:29:12.34

>>443
何のinvokeの話なのか知らないけど
ほとんどのInvokeメソッドとは全く違うんじゃないかな

>444
DataContractJsonSerializerSettings.UseSimpleDictionaryFormat

2019/06/15(土) 07:12:02.05

ConcurrentDictionary<Guid, ConcurrentDictionary<int, string>>
のようなデータ構造で、Value部の付け外しにlock機構って必要ですか？？

var cd = new ConcurrentDictionary<Guid, ConcurrentDictionary<int, string>>();

lock(_lockObj)
{
　if(!cd.TryGetValue ・・・)
　{
　　var child = ConcurrentDictionary<int, string>();
　　cd.TryAdd(Guid.NewGuid(), child);
　}
}

2つのスレッドがほぼ同時にアクセスしたとき、
最初に追加したValue部（ConcurrentDictionary<int, string>）を潰したくないです。

lock使うなら、普通にDictionaryでいいんですかね・・ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)

2019/06/15(土) 07:35:12.58

getとaddが不可分操作じゃないから要る

2019/06/15(土) 09:17:07.61

>>446
TryAddがfalseを返したら処理を最初からやり直せばいい
それならロックは不要
楽観的排他制御ってやつだ

2019/06/15(土) 14:37:59.48

HttpClientもWebClientもHttpWebRequestもまともじゃないのは一体なんなんだ

2019/06/15(土) 14:47:05.46

>>449
具体的には？

2019/06/15(土) 14:49:08.14

>>449
HttpClientはstaticなインスタンスでセッション使い回し。
このくらいの注意点は知ってるけどどう駄目なのか参考に教えてよ

2019/06/15(土) 15:37:24.10

>>449
KWSK

2019/06/15(土) 15:42:35.91

>>445
ありがとうございます！

2019/06/15(土) 18:51:55.25

>>449
これを使っている限りバグが出る可能性が排除できない
まともな設計で作り直してほしい

2019/06/15(土) 19:28:03.88

>>454
具体的には？

2019/06/15(土) 19:39:46.98

具体的なことは言えないレベルでなんとなく否定してるに1票

2019/06/15(土) 20:17:44.79

まあHttpClientFactory使えってなるよね、最近は

2019/06/15(土) 20:49:10.87

HttpWebRequestやWebClientは確実にゴミ

例えば非同期でいろんなサイトからダウンロードするアプリを作ろうとしても
実インスタンスが一つなので各サイトに合わせて設定できない

HttpClientはまともにusingできない使いまわし前提で管理が面倒でバグりやすい

2019/06/15(土) 21:25:13.03

>>458
>>457

2019/06/15(土) 21:28:36.81

いや知ってりゃ使えるだろってのはわかるんだが
なんでどれもこれも罠が満載なの？　っていう話ね

2019/06/15(土) 23:31:09.76

>>457
なにこれ？ナウなやつ？？

2019/06/15(土) 23:31:12.45

MacのCore2.1でデリゲートのシリアライズを試してるんだけどさあ、これって動くプラットフォームもあるってことなの？
class Program
{
static void Main(string[] args)
{
Func<int, int> A = i => i + 1;
BinaryFormatter formatter = new BinaryFormatter();
var tempStream = new MemoryStream();
formatter.Serialize(tempStream, A);
//System.Runtime.Serialization.SerializationException がスローされました
//"Serializing delegates is not supported on this platform."
}
}
レファレンスだとMacで動かないとか特に書いてはいなさそうだけど、どこを見たらそういう情報ってわかるんだぜ？
https://docs.microsoft.com/ja-jp/dotnet/api/system.runtime.serialization.formatters.binary.binaryformatter.serialize?view=netframework-4.8

2019/06/15(土) 23:37:24.81

>>462
ないでしょ
だってそれ、変数を一切キャプチャしないラムダ式以外では問題が起こるんじゃない？

2019/06/15(土) 23:54:10.26

デリゲートをシリアライズするっていう発想がそもそもなかったわ

2019/06/16(日) 00:04:36.79

ダメか、ありがとう

2019/06/16(日) 00:06:06.77

デリゲートのシリアライズはFullFWなら可能
.NET Remotingで通信先からRPCするために使う機能だ
.NET Coreでは.NET Remotingが廃止されたから、.NET Coreで使えないのは当然
そもそもBinaryFormatterはそれ自体が廃止された.NET Remotingの一部であり、互換性のためだけに残されてる遺物
今更新規に使っちゃダメ

2019/06/16(日) 00:12:52.39

>>461
うん、HttpClientのイケてないとこをラップして使いやすく（間違いを犯しにくいように）したやつ

2019/06/16(日) 00:22:01.61

>>466
正直、これが出来るとリモートプロシージャコールの受け側がif/switch羅列になるのを避けられると思っていました
しかし、これはもろに時代に逆行していたんですね・・・・
廃れたと言うことは今流のやり方もあるんですか？

2019/06/16(日) 00:27:11.51

.NET CoreでRPCしたいならRESTかgRPC使えとMS様は仰ってるね

2019/06/16(日) 01:01:25.28

gRPCを使用する場合でも、サーバからグローバルIPを持たないクライアントのメソッドを呼びたい場合にデリゲートシリアライズ化は有用なように思えてしまいます
接続を切らずにStreamで独自形式の命令を送り続けることになり、クライアント側では送られてきた命令を解析するためのswitch/if文だらけのコードになってしまうからです
でもif文羅列で正しいのかな・・・・どうなんだろう・・・・

2019/06/16(日) 01:18:24.92

プログラミング未経験からC#を勉強して1週間程の者です
疑問に思うことがふたつあるのでよかったら教えてください
ひとつめは配列の宣言について、宣言は省略せずにきちんとしたほうがいいのでしょうか？
また宣言する場合に
string[] array = new string[3];
と変数名を最初にstringで指定しているはずなのに、配列の数をstringで再び書くのはなぜでしょうか？

ふたつめは、
Console.Write("a は {0}, b は {1}", a, b);
と書くのは
Console.Write("a は " + a + ", bは " + b);
と書くより見やすいためでしょうか？

2019/06/16(日) 01:25:53.37

>>471
ひとつめ：varが使える場所ならvarを使った方がいい
ふたつめ：前者だと、文字列をconstやリソースファイルで保持してパラメーターだけ入れ替えられる（=使いまわしできる）。
ただ、最近はよほどパフォーマンスにシビアだったりリソースを再利用したい箇所でなければstring interpolationを使うことの方が多い（圧倒的に見やすいしバグも発生しにくいから）。

2019/06/16(日) 01:27:37.22

Console.Write($"a は {a}, b は {b}");
こうすると読みやすいしパラメーターの位置を間違える可能性が減る

2019/06/16(日) 01:52:02.63

C# は、面倒だな

Ruby の式展開(interpolation)では、
ダブルクォート文字列内に、#{式} で書くと、式の結果を文字列に変換してくれる

puts "a は #{ a }, b は #{ b }"

2019/06/16(日) 02:00:09.86

>>474
C#にもあるだろ。直ぐ上でも出てる。
$"a は {a}, b は {b}"

2019/06/16(日) 02:05:52.16

1つ上のレスくらい読んでくれよ…

2019/06/16(日) 02:12:46.91

string interpolationは参考にしておいたサイトでは見たことがなく初めて知りました
確かに圧倒的に見やすいですね
varを使うことで必然的に型を指定して初期化することになるので、その辺りの宣言はしっかりしようと思います
ありがとうございました

2019/06/16(日) 02:40:38.10

Rubyの人おかえりはこちらです

2019/06/16(日) 02:49:49.58

>>467
いいね！使ってみる。

2019/06/16(日) 05:00:17.20

interpolation 略して inpo

2019/06/16(日) 08:33:51.55

>>470
WebSocketとかSignalRとか使ったらサーバーからの通知対してにライブラリが適切なメソッドを呼んでくれるのでは