C#, C♯, C＃相談室 Part95

2017/10/17(火) 00:41:22.60

■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

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

2019/11/03(日) 00:17:01.38

>>172
芸列クラスと芸行キューを使う感じで書けばいいと思います。
https://docs.microsoft.com/ja-jp/dotnet/api/system.threading.tasks.parallel
https://docs.microsoft.com/ja-jp/dotnet/api/system.collections.concurrent.concurrentqueue-1

2019/11/03(日) 00:38:06.74

すみません。
芸列ではなくて並列でした。

>>173
ファイルをダウンロードして保存していく処理です。

>>174
ありがとうございます。
やってみます。

2019/11/04(月) 09:42:36.30

FormのMainMenu内のMenuItemとしてPanelやUserControlを表示するにはどうすればよいでしょうか？

2019/11/04(月) 10:13:49.85

すみません打開しました。

private UserControl1 UserControl1 = new UserControl1();

var menuItem = new ToolStripControlHost(UserControl1);

((ToolStripDropDownMenu)toolStripDropDownButton1.DropDown).ShowCheckMargin = false;
((ToolStripDropDownMenu)toolStripDropDownButton1.DropDown).ShowImageMargin = false;
toolStripDropDownButton1.DropDown.AutoSize = false;
toolStripDropDownButton1.DropDown.Size = new Size(UserControl1.Width, UserControl1.Height);
toolStripDropDownButton1.DropDown.Items.Add(menuItem);

2019/11/13(水) 09:04:11.57

メニュー項目をグレイ表示にしたりチェック記号など付けたいような場合、
MFCではOnUpdateXxxx()ハンドラでCCmdUIを使ったり、メニュー項目に
IDM_XXXXの様なID番号を付けておいて、そのID番号で操作することが
出来たのですが、C#で同様の事をしようとすると項目の表示順がそのまま
反映された0から割り振られた番号を使う必要があるようです。でもそれだと、
新しい項目を途中に追加した場合に番号がずれてしまいます。MFCと同様に
IDM_XXXX のようなID番号を付けたり、Updateハンドラで処理するような
方法はないのでしょうか？

2019/11/13(水) 12:10:20.10

MenuItemなりToolStripMenuItemなりのインスタンスを使えばいい
デザイナで配置してるならフィールドに置かれてる
変数名はデザイナでNameプロパティを変えれば追従する

2019/11/13(水) 23:53:39.67

>>178
MenuItemなら分からんけどToolStripMenuItemならTagプロパティがある
ただその用途だと各Itemをフィールドの配列かListで別管理したほうが楽

2019/11/14(木) 10:48:50.19

>>179
有難うございます。
メニュー項目に対応するインスタンス変数が存在していることすら知りませんでした。

2019/11/16(土) 00:42:57.25

Formアプリケーションを作っているとき、
例えば、Form1.cs, Form1.Designer.cs
Form1.resx(Form1.ja.resxなどになる場合も有りますが)
が組みになって作成されます。
Form1.csは人間がコードを書くためのもの、
Form1.Designer.csはIDEのデザイナが作成するもの
のように役割が決まっているそうですが、これらを互いに
関連付けているのはファイル名や拡張子なのでしょうか。
それとも、どこかに関連付いていることが記述されている
ファイルがあるのでしょうか？？？

2019/11/16(土) 00:44:19.89

csprojファイルに書いてある

2019/11/16(土) 00:46:32.43

>>182
お聞きしたいのは、
xxx.cs と xxx.Designer.cs のようなファイル名の「パターン」によって関連付けられて
いるのか、それとも、どこかのファイルに、書き方はわかりませんが、例えば、
Relation{ "xxx.cs", "xxx.Designer.cs" };
や
Form "xxx.cs" {
Designer : "xxx.Designer.cs"
};
のような感じで関連付けを書いてあるファイルがあるのか、ということです。

2019/11/16(土) 01:19:44.10

>>184
だからcsprojファイルに書いてある

**デフォルトの名無しさん** (ｽﾌｯ Sda2-CthP) · 2019/11/16(土) 01:20:36.88

>>184
クラスがpartial。
VSから見たときの関連性と言う意味では多分ファイル名だけど、コンパイルする時としてはpartialで同じ名前のクラスは纏められる。

というか昔はファイルわかれてなくて、regionの中に居た気がする。
partialが使えるようになった時にファイル分かれた。

**デフォルトの名無しさん** (ｽﾌｯ Sda2-CthP) · 2019/11/16(土) 01:24:27.50

csprojで、DependentUponになってるけど、ファイル名変えたら変な事になった気がする。
変えても良いんだっけ？

2019/11/16(土) 01:26:29.09

>>182
はたぶん自動的にサブタイプになる設定がどこかに定義されてるかを聞きたいんだろうな…

2019/11/16(土) 09:28:48.15

>>185
こんな風になっています。例えば、クラス名が Form1 で、ファイル名も Form1.cs
になっていますが、もしクラス名とファイル名を異なるようにしてしまったり、
Form1Designer.cs のファイル名を変えて、WindowsFormsApp1.csproj の中の、
Compile Include を変えたりしてしまった場合、果たしてどうなるのでしょう。

【Form1.cs】
namespace WindowsFormsApp1
{
　　public partial class Form1 : Form
　　{
　　　　・・・
　　}
}

【Form1Designer.cs】
namespace WindowsFormsApp1
{
　　partial class Form1
　　{
　　　　・・・
　　}
}

2019/11/16(土) 09:29:13.19

>>189
【WindowsFormsApp1.csproj】
<ItemGroup>
　<Compile Include="Form1.cs">
　　<SubType>Form</SubType>
　</Compile>
　<Compile Include="Form1.Designer.cs">
　　<DependentUpon>Form1.cs</DependentUpon>
　</Compile>
　・・・
　<EmbeddedResource Include="Form1.en.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　<EmbeddedResource Include="Form1.ja-JP.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　<EmbeddedResource Include="Form1.ja.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　<EmbeddedResource Include="Form1.resx">
　　<DependentUpon>Form1.cs</DependentUpon>
　</EmbeddedResource>
　・・・
</ItemGroup>

2019/11/16(土) 09:45:51.65

>>182
Visual Studioの設定や機能の話は該当するＶＳのバージョンのスレでやってくれ

2019/11/16(土) 11:16:34.71

>>189
試してみれば？

2019/11/16(土) 14:34:42.64

VSが入れ子表示してるファイル名と、コンパイラがコンパイルするクラス名は別の話だからな
VSが入れ子表示する話やデザイナファイル作る話ならVSスレ行ってやってくれ

2019/11/16(土) 15:38:12.07

緊急で質問です。
Windowsフォームのコンボボックスにて、フォーカスされた時の背景色を青ではなく薄水色にしたいのですが、やり方がわかりません。
ネットで調べてもほとんど引っかかりません。簡単なソースコードサンプル付きで教えてくださる優しい方がいらっしゃいましたら、よろしくお願い申し上げます。

2019/11/16(土) 16:48:11.20

>>194
それは緊急ですね。
ネットで調べるとたくさん引っかかりますよ。
https://stackoverflow.com/a/13212571/
https://stackoverflow.com/a/11650321/
https://stackoverflow.com/a/24476009/
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.combobox.drawitem

2019/11/16(土) 17:41:51.10

>>194
緊急とか書くと自分の都合しか考えない身勝手な奴だと思われるよw
いやマジで。
すでにからかわれてるけど。

やっつけならこれでいいのでは？
ちゃんとやるならCombobox継承してOnDrawItemをオーバーライドする
private void comboBox1_Enter(object sender, EventArgs e)
{
　　var bc = comboBox1.BackColor;
　　comboBox1.BackColor = Color.Azure;
　　EventHandler leave = null;
　　leave = (sencer, ev) =>
　　{
　　　　comboBox1.BackColor = bc;
　　　　comboBox1.Leave -= leave;
　　};
　　comboBox1.Leave += leave;
}

2019/11/16(土) 18:34:21.65

>>189-190
プロジェクトファイルをバックアップしておいてから、
クラス名・ファイル名などを変えて、プロジェクトファイルがどう変わるか、

diff・VSCode などで、比べてみれば？

2019/11/16(土) 19:58:19.51

>>197
ソリューションエクスプローラー上の、Form1.cs上で、右クリックして、
出てくるメニューから「名前を変更」を選んでファイル名を変更したところ、
Form1.Designer.csのファイル名も連動して変更される現象を発見しました。

2019/11/16(土) 21:35:50.24

>>198
さらにこのとき、クラス名も Form1から新しいファイル名に対応したものへと
自動的に修正され、*.csproj 内の関連名も全て変更になります。

2019/11/17(日) 07:31:12.67

これからGUIデスクトップアプリ作り始めるなら、.net framework 4.8と.net core 3.0 どっちがいいの？
.net core のほうはGUIデザイナがないのがなんか気になる。
今書いたGUIデザインソースが.net 5 でGUIデザイナが出てきた時にうまく認識されずに全部書き直しになるんじゃないか不安になる。

2019/11/17(日) 07:37:16.91

Blazorがいいよ

2019/11/17(日) 07:58:55.17

Client-side Blazorすら正式版が出てないのに。

2019/11/17(日) 08:27:12.76

Unoがいいよ

2019/11/17(日) 12:01:58.08

>>200
ソースは使い回せるから好きなほうでいいよ
デザイナほしいなら.Net Framework

2019/11/18(月) 14:21:42.81

.NetCoreでMingw64のBashで表示できるプログラムって作れないのですか？

2019/11/18(月) 20:06:09.61

>>205
そもそも、Windows上のbashはWinアプリなら全て実行できます。

2019/11/20(水) 12:30:53.34

CefSharp使うと一瞬画面が消えるんですけどなんとかなりませんかね？

2019/11/23(土) 09:13:16.39

C#で作ったコマンドラインアプリで例外が原因でアプリが終了した場合の
終了コード（バッチだとERRORLEVEL%で見れる値）が仕様でどうなってるか教えて。

単純にMainでSystem.Exception投げるだけのプログラム組んだら-532462766だったけど、
typeof(System.Exception).GetHashCode()あたりかなと思ったけど違ったし……

2019/11/23(土) 09:21:08.42

returnで終了コード返すのはダメなの？

2019/11/23(土) 09:29:14.61

実用上はtrycatchしてreturnすりゃ問題ないけど、これ何の値なのかなーと。

2019/11/23(土) 11:13:28.16

16進数に変換してググると何か分かるかもね

2019/11/23(土) 11:38:50.28

/h　-h 等でヘルプを出力がよくあるパターンだな

2019/11/24(日) 00:34:51.49

>>208
16進数に直すと、 0xE0434352 で、16進数の最後の3つは、ASCII CODEの
"CCR"になっており、「時間の霧で意味が失われる」という意味の頭字語
になっていて、corexcep.h の中の EXCEPTION_COMPLUS で定義されている。

https://stackoverflow.com/questions/35294313/exit-code-when-unhandled-exception-terminates-execution
On Windows, a .NET process normally exits with the SEH exception code value,
the one that got the process to crash and terminate. Usually -532462766
(aka 0xE0434352) for a managed exception. Last 3 hex pairs spell "CCR",
an acronym whose meaning is lost in the fog of time, declared as
EXCEPTION_COMPLUS in corexcep.h. Sample question is here.

https://github.com/dotnet/coreclr/blob/master/src/inc/corexcep.h

#define EXCEPTION_MSVC 0xe06d7363 // 0xe0000000 | 'msc'
#define EXCEPTION_COMPLUS 0xe0434352 // 0xe0000000 | 'CCR'
#define EXCEPTION_HIJACK 0xe0434f4e // 0xe0000000 | 'COM'+1

2019/11/24(日) 00:48:09.56

>>223
"CCR" は、「時間の霧で意味が失われる」という意味ではなく、
昔は何らかの英語の言葉の略語だったが、今となっては何の意味だったか
誰も思い出せなくなってしまったよく分からない略語、という意味らしい。

2019/11/24(日) 19:54:50.84

>>213
おお、詳細な情報ありがとう。

こっちも仕様をあたってみたけどC#の言語仕様もCLIの方もそれらしい記述は見当たらなかった。
まぁ英語苦手だし見落としてる可能性もかなり高いけど。

2019/12/03(火) 18:29:27.61

XML処理しなきゃいけなくなってコード組んだんだけどXDocument×LINQの組み合わせが楽すぎた
XML扱う上でC#は最強の言語なのではなかろうか。併用するライブラリの都合上C++/Pythonも考えたけど勝負にならんかったわ
他にXML使うのに便利な言語ってなんかある？

2019/12/03(火) 19:11:05.07

powershell

2019/12/03(火) 21:27:27.34

xslt

**デフォルトの名無しさん** (JP 0H79-e23S) · 2019/12/05(木) 14:46:16.32

以前に、const での定義名は、defineで定義したものに上書きされることがあるので
全部大文字で名前を付けないでPascal形式で付けるのが正しいらしいって質問をしたものだけど

そもそもC#ってdefineで定数作れないな
それでもPascal形式で名前つけたほうが良い？

2019/12/05(木) 15:24:41.41

MS推奨はPascal

2019/12/05(木) 15:28:13.82

>>219
Pascalにする慣習だしMSもそう推奨しているから従うだけ
命名規約はそれが存在し統一されていること自体に意味があるのであり、機能的な理由付けを求めることはナンセンス

2019/12/05(木) 16:33:23.52

昔はXML最強だと思ってたけど
jsonやyamlの天才的な手抜きにに触れて考えが変わった

2019/12/05(木) 17:22:34.08

>>219
constであることを意識させる必要がもしあるならFOO_BAR形式は決して悪くないと思う。
ただ、その必要性があるケースってよく考えるとあんまりないんだよね。

2019/12/05(木) 18:16:38.66

ぶっちゃけMS自身もconstが全部大文字だったりPascalだったりしてる
細けェことは気にすんな
命名なんて気分だ気分

2019/12/05(木) 19:17:29.95

C++→C#と来て久しぶりにC#に戻ったらC++の面倒くささに驚いた

2019/12/05(木) 19:18:00.89

C++に戻ったらの間違い

2019/12/05(木) 22:20:07.57

>>222
JSONはいいかげんコメント書けるようにしろよ

2019/12/05(木) 22:28:30.57

>>227
コメントというデータを仕込めばいいんじゃね？

2019/12/05(木) 22:56:27.93

ラベルダブルクリックでテキストがコピーされるのに初めて気づいた
何でこんな余計な機能つけるんだよ。せめてプロパティでオンオフできるようにしとけよ

2019/12/05(木) 23:33:27.61

>>228
そういうバッドノウハウに頼りたくない

2019/12/06(金) 12:42:16.61

JSONの"再発見"者ニキ「JSONにコメントを書けないようにしておいてよかった」

2019/12/06(金) 12:55:10.38

>>230
じゃあ、RFC4627 に口出しできる立場になって、自分で提唱すれば？

2019/12/06(金) 12:56:20.84

何がじゃあだよガキかw

2019/12/06(金) 13:58:14.26

どこがガキなのかわからん

2019/12/06(金) 21:08:55.37

えっ？
いきなりRfCとか言い出す>>232なんてガキの思考そのままだろw

2019/12/06(金) 22:18:00.52

なるほどガキらしい考えだ
ママに聞かせて褒めてもらいな

2019/12/07(土) 14:40:03.37

規格が気に入らないなら、それを変更するように影響を与えないといつまでも変わらない。
規格が気に入らない。可能な代替案も気に入らない。って喚いてるだけじゃん。
どっちがガキだよlol

2019/12/07(土) 15:36:41.80

>>237
敵対する言語の信奉者や作者が批判してしている可能性もあるんだから、
委員会に提案しない事が後ろ向きとは限らない。

2019/12/07(土) 17:37:24.28

>>237
そういうのを書生論って言うんじゃないかな？w
その実現可能性ってどの程度？
まあ、ガキだよねやっぱり。悪いけどさ。

そもそも>>227の人はそんな話（どうやったら変えられるか？）なんかしてないんじゃないのかな。
病気の人をからかう意図はないけど、アスペルガーとかじゃなかそんなの普通に分かるよね

2019/12/07(土) 17:47:06.56

ふらっとだけじゃなくここでも人格批判かよ
板違いだから余所でやってくれ

2019/12/07(土) 17:50:57.13

>>237
ほんそれ
叩いてる奴らはバカ類だからほっとけ

2019/12/07(土) 18:02:30.43

>>239
> アスペルガーとかじゃなかそんなの普通に分かるよね
せめて日本語がまともに使えるようになってから出直してこいよ

2019/12/07(土) 18:02:39.31

>>241
いや、C++を直して欲しくて書いているとは限らない。
良いアイデアを敵に与える必要はないので、提案などするひつ世はない。

2019/12/07(土) 18:07:14.42

>>243
あれ、JSONの話だった。

2019/12/07(土) 18:12:42.05

>>238
よくわからないんだけどC#と敵対してる言語ってなに？

2019/12/07(土) 18:21:09.76

大多数のC#erが敵と感じることが多いのはVBじゃないかな
MS的には敵はGoやJavaと言いたいだろうけど、まだまだC#は(Unityを除けば)Windowsでしか使われておらず、プラットフォームの制約で仕方なく選ばれる言語の域を出ない
その上でVBを選ぶかC#を選ぶかは完全に好みの問題なわけで、
そこで好みを優先できる組織ならそもそもサーバーにWindowsなんか採用しないよね

2019/12/07(土) 18:28:17.16

>>245
自分の好きな言語を広めたいと思っている人も居るわけですよ。

2019/12/07(土) 18:37:40.00

>>247
答えになってないんだけど
君が「C#と敵対している」と考えてる言語って何？

2019/12/07(土) 18:50:47.69

>>248
黙秘権を使います。

2019/12/07(土) 20:35:07.03

>>246
もともとunsafeなんかはC#だけだったけど
最近のバージョンは他の部分でも差が付いてるので
好みの問題だけじゃなくなってきてる

2019/12/07(土) 20:48:48.93

さすがに今どきVB.NETは有り得ないんじゃね？

2019/12/07(土) 20:53:05.32

ここ数年VBなんて見てないわ
他の選択肢が多すぎて選ぶ人なんて居ないだろう

2019/12/07(土) 22:43:02.88

1. 設定値を入力する画面がある
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの変数に値を渡す
3. 他クラスは画面の値でなく、設定用保管クラスの変数の値を参照する

みたいなクソ仕様のアプリを書いてしまいました。
なんで直接、設定値入力画面の入力値を参照しないのか・・・。
仕様を直したいんだけど、もうクソ長いコード書いてしまっていまさら直すのも数日かかりになりそう。。。

2019/12/07(土) 22:44:22.12

>>253
これやっぱり直すべきでしょうか・・・・。
工学系の院生の研究用アプリです。

2019/12/07(土) 22:46:49.22

普通じゃね？シリアライズするなら当然そうしねーか？

2019/12/07(土) 23:08:25.55

C#関係ないようなｗ
設定値の復帰させるとかでも一括で管理する部分あった方が取り回し楽になるし何がクソなのかもわからない
>>254
むしろ該当部分組みなおすのに数日かかってしまう形になっているのが問題では

2019/12/07(土) 23:09:21.20

>>253
言ってること誤解してるかもしれないけど、
UIの入力をダイレクトに設定に反映しないのはMSのお作法的には
むしろ正しいんじゃないの？

適用かOKをクリックするまで入力が設定に反映されず、キャンセルボタンを
クリックすると何もなかったことになる仕様なんだよねたぶん？

まあ、仕様が適切かどうかは要件次第だと思うんで、あんまり教条主義的に考えない方が...
要は使いやすければそれでいいんで

2019/12/08(日) 00:00:10.40

大まかな設計は悪くないと思うけど、
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの「変数に値を渡す」
3. 他クラスは画面の値でなく、設定用保管クラスの「変数の値を参照する」 (画面の値でも同様によくない)
って仕組みは直した方がいいんじゃないかな
一箇所仕様を変えたら全部が狂うとか、変なことが起きてくるんじゃないの

2019/12/08(日) 00:29:06.09

>>258
まさにそこなんですよね。。。
他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。

2の変数の名前とか少し替えるとどこで参照先を全て直さなければいけない。
この仕様直したいんですけど、時間がかかるのと単純作業を繰り返すので、
考えただけで目眩がします。

2019/12/08(日) 00:38:02.22

え？何が悪いのかさっぱりわからん
～すればってのも俺には的外れに見える

2019/12/08(日) 00:50:00.57

>>259
変数の名前ならVisual Studioの機能で簡単に一括変更できるぞ
https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/rename?view=vs-2019

2019/12/08(日) 01:02:05.03

変数名の変更はVSの機能で一発で済む
vsじゃなくても最近のIDEなら標準的な機能じゃないかな？

書いてある設計自体は普通でクソだとは思わん
設定値が1万個くらいあってそれを1個のclassに全部ぶち込んでるとかだと整理したほうがいいんじゃね？って思うけどそういうわけでもないんでしょ？

画面ロックすればよかったって言ってるってことはあとから値変えられて困ってるってこと？
登録ボタンなんて作らずに画面上の設定値が変更されたら即座に設定値管理用classに反映させればいいのでは？

2019/12/08(日) 01:04:08.10

>>262
それやると設定値にチェックが必要なとこで詰むぞ
やめるべき

2019/12/08(日) 01:06:23.59

>260
同じく、何がくそ実装なの分からない
普通はGUIの変数を直参照しちゃってるから>>253の2,3みたいに直したいって悩みそうなもんだけど

2019/12/08(日) 01:06:29.61

開始日、終了日の入力で
開始日から終了日の期間に制限がある場合とかバインドに弱い
開始値、終了値も同様

2019/12/08(日) 01:13:11.42

>>263
いや、何も詰まないけど？
反映するときにチェックして異常値であることがわかればいいじゃん
登録ボタンで登録時にチェックしてエラーとするのと何らかわらん

設定値保持classは常に正常な値のみを保持する
って要件ならそら無理よ

2019/12/08(日) 04:54:32.09

>>259
前の書き込みじゃわからなかったけど、主要な心配は、コードの保守性の問題じゃなくて処理中の入力に対する問題なの？
もし後者なら本当に作り直しレベルかも・・・・・

2019/12/08(日) 06:45:15.65

WPFとかだとそういう風に組むのが推奨されてるし

2019/12/08(日) 08:21:03.71

>って要件ならそら無理よ

このことを「詰む」って言ってたんではないかと

2019/12/08(日) 08:33:51.79

DocumetViewとかMVVMパターンでは普通の実装だね。

2019/12/08(日) 10:03:29.48

>>266
だからいつ？
ちゃんと考えて

開始と終了の期間に制限があるんだよ
組んだことないの？

2019/12/08(日) 10:24:22.87

>>264
>>267

1　画面に数値を保持して、開始ボタンを押すと画面入力はロックする
3　クラスは1の画面上の値を直接読みに行く

とすると2はいらなかったのかなと。

2があると、設定を増やしたり変数名を変更するたびに1→2→3全部直さなければいけず、
保守が面倒くさいので、後でソースを見た人にブチ切れられないかと・・・。
あと、画面上なら間違って他クラスから値を書き換えることはしないと思うのですが、
変数だと他クラスから不用意に値を書き換えてしまわないか不安で。。。

2019/12/08(日) 10:25:27.96

自分で途中からクソ仕様と思い始めてしまったんですが、これが標準なんですかね。
だとしたら安心して引き継げるのですが。

正直面倒くさくて直したくないorz