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/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

2019/12/08(日) 10:29:01.88

>>272
画面に範囲guyのヤツブチ込んでも誰も死なんの？
コントロールだから絶対に想定guyのヤツは来ないはないよ

2019/12/08(日) 10:34:32.17

>>272
>変数名を変更するたびに
vsなら参照してるところもすべて書き換える機能あるよ

2019/12/08(日) 10:48:39.51

>>273
引き継ぐならそのままにしてあげたほうが良い
わざわざ手間をかけて設計を壊して後任の恨みを買う必要はない

2019/12/08(日) 10:56:36.45

>>272
ちょっとした吐き捨ての設定ならそれで問題ないかもしれないけど、入力の項目が多くなってアプリを開いてあの設定を保存して呼び出したいってなった時とかどうすんの？とか結局仕様と設計の問題じゃないか？

2019/12/08(日) 10:57:28.44

>>273
てか、WinFormなの？それともWPF？
自分のこだわりがないならとりあえずフレームワークの流儀に倣ってりゃいいんじゃね

2019/12/08(日) 11:04:44.31

画面遷移されたら消えるの？
たまたま今回画面遷移せんの？
問題が起こりまくるから止めろと言っておく
コントロールの不正な入力を完璧にガードするのはよく知ってる奴でも結構難しいときあるし

2019/12/08(日) 12:32:23.17

>>271
ユーザーが設定値を変更したとき
そうやって突っ込むってことは
>設定値保持classは常に正常な値のみを保持する
って要件はないんだよね？
開始終了とか関係なくユーザーが設定した値保持するだけじゃん
mvvmとか見たこと無いの？

2019/12/08(日) 12:50:54.37

>>280
開始に1980/01/01
終了に1980/02/01
が設定されてたとき
期間に3ヶ月って制限がかかってたときに
開始と終了に2019/09/01-2019/10/01を設定したいとするわな？

よし、じゃ、開始に2019の・・・エラー!（終了に1980/02/01が入ってるので）
じゃ、終了に2019の・・・エラー!（開始に1980/01/01が入ってるので）

詰んだじゃん

2019/12/08(日) 12:55:17.97

>>275
それやったんですけど、なんか変更されないところも出てきて・・・。
ここ以外で変なことやってるのかもしれません。

2019/12/08(日) 12:56:57.51

>>279
開始ボタンをおしても、設定入力画面は開いたままで画面遷移させてないんですよね。

2019/12/08(日) 12:59:14.97

みなさんのお話を聞いていると、
登録ボタンを押して、変数記録クラスに画面の値を記録させるというのはクソ仕様ではなかったんですね。
ホッとしました。