C#, C♯, C＃相談室 Part93©2ch.net

2017/04/22(土) 08:52:00.93

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

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

■前スレ
C#, C♯, C＃相談室 Part92
http://echo.2ch.net/test/read.cgi/tech/1485589613/

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

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

2018/04/17(火) 11:51:31.97

おっ！
いいこと教えてもらった。
Rxってsilverlightだけじゃないんだ。

2018/04/17(火) 12:18:07.14

そんなの使えるなら.NET4だって使えるでしょw
3.5が使えて4が使えないプラットフォームは存在しないと思うけど

2018/04/17(火) 12:48:49.14

そういう問題じゃないんだよ・・・

2018/04/17(火) 13:03:19.02

お客様のPCがWindows7ならデフォルトで3.5が入ってるでしょう。4.0にしてから使ってくださいとは言いずらい。

2018/04/17(火) 13:07:10.43

ちょっと前までUnityも3.5止まりだったから多少はね?

2018/04/17(火) 16:37:52.80

Rxってなんぞや！！

2018/04/17(火) 17:17:34.43

gugure

2018/04/17(火) 19:00:52.03

ググれは正論だけど、せっかく話題になったんだからここの住民の意見も聞いてみたい。使ってる人の感想とか。

2018/04/17(火) 19:14:49.95

せや！Rxについて詳しく

2018/04/17(火) 19:54:15.01

全然関係ないけど、receiveの略が何でRxなのか昔から結構謎

2018/04/17(火) 20:38:22.07

それ組み込みの世界だね。送信ポートはTxだ。スレチだね。

2018/04/18(水) 14:53:40.81

インストールされている証明書の読み取り、エクスポートをやりたいんだけどさ
ググるといろいろ出てきてX509とかってのを使うと良いとある
まだ実装とか全然なんだけど、この情報だけだと不安なのでだれかやったことのある人いない？

X509Cartificate.Exportはバイトデータを吐き出してそのままファイルに保存できるるっぽいけど、秘密キーを設定したいとかあったりしてモヤモヤしてる

2018/05/03(木) 18:58:35.37

ﾜｯﾁｮｲなしスレが1000行ったからこっちをage

2018/05/03(木) 18:59:21.23

ageられてなかった…

2018/05/04(金) 20:04:32.00

windowformアプリケーションで

form1 ディスプレイの解像度等を入力する。入力したデータをもとにform2に表示する長方形の大きさ（rx,ry)を算出
form2 form1で算出した（rx,ry）をもとに長方形を表示

ってしたいんだけど

A. rx,ryをpublicで定義してform2.csから参照する
B. form1のrx,ryを求める計算式をクラスにしてform2からインスタンス生成して求める

のどちらがお作法的に正しいんでしょう？

2018/05/04(金) 20:12:02.30

データとUIを分離するとして、データ保持と計算用のクラス、formは入力のみ、表示のみって感じになるのかな
でも、まぁそんなのAでもBでもいいだろ

関係ないが解像度ぐらい自動で取得してくれると楽

2018/05/04(金) 20:14:46.22

なんとなく、こういうのを"お作法"と呼ぶマにはいいイメージがない

2018/05/04(金) 20:20:22.68

>>168
ありがとうございます。
解像度は自動取得なのでディスプレイの㎜サイズでした。

2018/05/04(金) 20:22:53.75

>>169
すいません。
プログラミング初めて勉強なので、なるべくへんなコーディングしないように可読性高くと考えてまして、
普通はどう描くんだろうなというところが気になって仕方ない。
public変数作りすぎると、後でどこかで変に触るとわけわからんことになるのかなと極力使わないように心がけてます。

2018/05/04(金) 20:37:07.58

何かフリーソフトを作ってみたくて勉強しているところなのですが、GUI？を学ぶ上で良い本があれば教えていただきたいです

2018/05/04(金) 20:55:12.49

>>171
フォームは入力の受付と出力の描画だけをする
内部で使うデータはモデル側で持つ

2018/05/04(金) 21:33:04.91

>>173
それでいってみます。
ありがとうございます。

2018/05/04(金) 21:34:38.54

連投すいません。

ユーザー側でフォームのサイズを変えたとしても
常にフォーム右端にボタンを固定する方法ってないでしょうか？

2018/05/04(金) 21:39:42.44

>>175
ボタンのAnchorのプロパティをTop, Rightに変更

2018/05/04(金) 22:00:01.60

>>176
Anchorって設定があったんですね。
できました！
ありがとうございます。

2018/05/04(金) 22:18:10.81

Form1で作成したmethod1をForm2で使用したい場合どのようにすればいいのでしょう？

Form1.method1();

だとエラーなのですが、form自体がクラスだからインスタンス生成が必要ということでしょうか？
本当に初歩的な質問ばかりですいません。

2018/05/04(金) 23:14:52.98

駄目だ煮詰まってきた。

Visualstudioで新規ソリューションを作成して、既存のソリューションからフォームを追加したのですが、
フォームデザインでは新規フォームが表示されているだけ、.Designer.csを除くときちんとコードが記載されているのですが、
[デザイン]:の画面では反映されておらず、この画面でコントロールを追加などするとエラーがでてビルドできなくなります。
フォームの追加の仕方が間違ってるのかなぁ。

2018/05/04(金) 23:16:00.99

煮詰まる＝完成する

2018/05/05(土) 01:05:27.05

>>179
エラーの内容は？

2018/05/05(土) 08:03:54.33

>>181

エラー CS0121 次のメソッドまたはプロパティ間で呼び出しが不適切です:
'InitalMonitorSetteing.InitializeComponent()' と 'InitalMonitorSetteing.InitializeComponent()'

エラー CS0111 型 'InitalMonitorSetteing' は、'InitializeComponent'
と呼ばれるメンバーを同じパラメーターの型で既に定義しています。

です。

2018/05/05(土) 08:08:30.21

ソリューションエクスプローラーで
追加→既存の項目
でフォーム一切合切を取り込むと
フォームの[デザイン]タブのところで新規のフォームが表示され、これをいじると上記エラーが出ます。
フォームの[デザイン]タブをいじらなければ正常に実行されます。

.Designer.csを見るときちんとコードが書かれているので
[デザイン]と.Designer.csが一致していない状態になっているようです。

2018/05/05(土) 08:36:55.68

地道に

フォームのデザインすべてコピー貼り付け
コードすべてコピー貼り付け

ってやって追加しました。
なんかネットで見ると、

ソリューションエクスプローラーで
追加→既存の項目
でフォーム一切合切を取り込む

ってやると後々まで得体のしれないエラーに悩まされるので、上の方法を推奨している方がいました。
Visual Studioかフォーム自体の持つバグなんですかね…。

2018/05/05(土) 08:47:39.95

～VS2015しか使ってないが俺はエラー起きたことないよ。原因分からないけど、何かやらかしてるんでしょ

2018/05/05(土) 09:57:21.01

無闇にコピペした結果を環境のバグとか
プログラム向いてないよお前

2018/05/05(土) 10:00:36.87

失礼しました。
私がよく理解していないために、しなければいけない作業をしていないのかもしれませんね。

2018/05/05(土) 10:35:22.91

むしろしちゃいけない作業をしてるような気がする...

2018/05/05(土) 11:08:14.41

>>178
そもそもこの質問の時点でFormsのコード部分が何をやってるのか理解できてない可能性がある

2018/05/05(土) 11:25:44.32

いきなり難しいことをやろうとするとダメやね

2018/05/05(土) 11:27:18.98

基礎も身につけずに一端のフリして解決しようとして、半端で折れるバカってのはよく聞く話

とりあえず何か入門書籍に頼って動くものを作れ
話はそれからだ

2018/05/05(土) 20:20:18.85

>>184
情報共有する場所なんだからこういったいいかげんなこと書くのやめてほしいな
まずソースをそのまま取り込みたいのならプロジェクトに追加で何も不具合は起こらない
それでデザイナが反映されないのならDesigner.csを直接書き換え(認識できなくなるような書き換え）やっているはず
あとユーザーコントロールを内部で追加している場合は一度ビルドするとデザイナで反映される
プロジェクトでなくソリューションにソース追加しても当然何も起こらない
最初からふらっとにいけばいいのに

2018/05/05(土) 20:30:34.54

WinFormのデザイナは中途半端に内部実行するからしょっちゅうトラブるんだよな
コンストラクタでなんかやってる奴は特に要注意

2018/05/05(土) 22:08:57.94

デザイナかどうか判断するコードを書くのは飽きた

2018/05/05(土) 22:38:59.04

そんなあなたに！WPF！

2018/05/05(土) 22:40:45.58

フォームをコントロール含めて継承すると継承先でコントロールの編集ができなかったり云々
という書き込みを見たので、
そこで提案されていた新規フォーム作成して
そこにコピペとしてみて結果オーライだったのでそれで良しとしたのですが、
私の方でなにか既存のフォームを取り込むのにまずいことをしてたのかもしれません。
記憶にないけどDesigner.csを直接書き換えしたかなぁ・・・。

フォームで作成するかWPFを使うかを悩んでた時にフォームは放置されたバグが多いと警告されていたので、
単純にバグなのかと思いましたが根拠なくソフトのバグと書き込むのはまずかったですね。
失礼しました。

2018/05/06(日) 07:44:34.64

FormかWPFか悩んでるならWPFを推す。
最初は難しいがXAMLはUWPでも使っていて今後につながると思う。

2018/05/06(日) 15:08:05.14

今後ピクセル単位でのUI作成は完全に無くなるからなぁ

2018/05/06(日) 16:52:40.62

多段継承してるカスタムコントロールはぶっ壊れやすい
Winアプリ作らにゃならんならWPFのがマシってのはまあそうだ
でも将来性あるとは思わんな

2018/05/06(日) 17:34:01.02

WPFそのものの将来性はともかくとして、その技術のエッセンスが次代に引き継がれると思うんです。
今後もWinアプリを開発することになるんで、なるべく将来性と言うか潰しのきく技術に投資したいと思ってWPFにしたんだけど。

2018/05/06(日) 17:36:34.98

>>199
それはないよw
継承の段数は関係なくて、単にコントロールのカスタマイズは意外と難しいってだけの話

俺も経験があるけど簡単にシステム側のバグを疑いたくなる現象にぶち当たるけど、
ほとんどの場合はプログラマの理解不足によるユーザーコード側のバグが原因

2018/05/06(日) 17:37:23.44

潰しがきくってんならなおさら独自仕様なんぞあかんやろ
WPF出てから何年経ってるよ
他に採用してるとこないのはそういうことだ

2018/05/06(日) 17:39:54.31

>>202
XAML

2018/05/06(日) 17:41:16.14

>>201
いや正確にはシステムがぶっ壊してるんじゃなく
レイアウト決定だの初期化順番だので罠にはまる確率がガンと上がるって話
コントロール1種を少々カスタマイズしたくらいじゃあんまハマらんさ

2018/05/06(日) 17:43:51.97

GDIが使えない時点でゴミ
WPFでCADを提供してみろ

2018/05/06(日) 18:14:23.28

>>202
対案示してくれると検討もできるんですけど。

2018/05/06(日) 18:17:03.64

>>206
オプショナル独自仕様なんぞわざわざ覚えんでもC#だけ抑えときゃいいじゃん

2018/05/06(日) 18:17:55.59

formとwpfどっちかじゃなくて、状況に応じてどっちか使えばいい
言語だってそうだ。c#に拘らず、必要に応じてほかの言語も使えば楽になるぞ
縛りプレイとか馬鹿臭くてやってられん

2018/05/06(日) 18:18:35.39

何でこのスレ来てるの？

2018/05/06(日) 18:21:30.52

xamlが単なるコードトランレート言語だったなんて知らなかったんだよ。

2018/05/06(日) 18:31:06.82

>>207
まさかの浅い答えでしたね。
今時、なんか開発する時は言語だけじゃなくAPIとかプラットホームとのセットじゃないの？

2018/05/06(日) 18:36:24.83

最近form触る機会あったけど、WPFになれた後だとバインディングが面倒でならない
formはformでわざわざ部品探したり作る必要ないから良いんだけどね

2018/05/06(日) 18:49:36.56

Bindingが遅すぎて使い物にならない

2018/05/06(日) 19:05:20.38

なんか変なイチャモン付けてる人いるけど。
CAD作れるかとか、Formならできるの？
Windows、.net、C#でGUIアプリ作るならFormかWPFしかないじゃん。
Formは終わった技術で行き止まり、WPFは普及しなくて過渡的な技術になるかも知れないがその先につながりそうでって言ってんです。
もっと論理的に反論して欲しいです。

2018/05/06(日) 19:06:34.14

昔から居ついてるから一々突っからなくて宜しい

2018/05/06(日) 19:13:48.84

>>215
昔から居てもアホな書き込みすると初学者は惑わされるのよ。
自分が理解出来ない技術はみんなダメって言ってないか？
ちゃんと論理的に反論してよ。
出来ないなら駄まってろ。

2018/05/06(日) 19:15:40.37

formでCAD作ってる奴ぐぐると日本人でも複数いるよ

2018/05/06(日) 19:17:40.07

>>214
お前さんみたいな銀の弾丸求める奴ぁ先がないぞ
XAMLは文字列だらけで設計の筋がいいとは到底言えない
もし次があるなら全然違うもん出してくるんじゃないの

2018/05/06(日) 19:21:54.60

>>217
FormでできるならWPFでもできるだろう。
Formの優位性は何？

2018/05/06(日) 19:24:56.35

>>218
XAMLは面倒よ、たしかに。
でもね、オレは使ってないがGUIのリソースエディタがあるんじゃないか？
なくても直ぐにできるよ。

2018/05/06(日) 19:27:17.19

>>218
UWPもXAMLだよ。
MSは当面これでいくんじゃないの。
あんたよりMS信じる。

2018/05/06(日) 19:34:40.78

XAMLの筋が悪い一例としてIDEサポートがHTMLにすら劣る点が上げられる
今でも時々vsごと落ちる
まあ次が出る前にWinアプリ自体がオワコンになる可能性も低くないけどな
あんたの人生だから好きにしたらいいよ

2018/05/06(日) 19:44:28.98

>>222
XAMLでの開発3年弱だがVS落ちた経験ないよ。
Winアプリがオワコンになるんだったら、早いとこ他の言語・環境に移行したら？
オレはWinアプリだけじゃなくタブレットとかスマホにも適用できると思ってるから、この道行くよ。

2018/05/06(日) 19:47:05.22

>>222
俺も落ちたことないんだけど、どんな環境で何したん？

2018/05/06(日) 19:59:30.59

WPFはもちろん最良ではないけど
すくなくとも現行のUWPと共通のXAML使ってるぶんFormsよりは十倍マシ

2018/05/06(日) 20:10:59.67

メモリ8Gで5段くらいネストした奴編集してたらストンと落ちたぞ
vs2015だ

>>225
「現行では」比較論でまあせやな
将来性は怪しいが

2018/05/06(日) 20:17:33.07

>>226
ハードウェアアクセラレーションの問題ではなくて？

2018/05/06(日) 20:19:15.57

>>226
すごいな。なかなか落とせるもんじゃない。
そんなにWinの将来に悲観的なら、本当にどこかに行ってください。
間違った書き込みを堂々と恫喝的にされると初学者の道を誤らせるよ。
それって罪なことです。
このスレタイでは。

2018/05/06(日) 20:22:22.92

>>228
落ちるときは落ちるさ
こんな風にその問題を追及しないのがアレ
https://stackoverflow.com/questions/31021049/visual-studio-2015-crashes/33182194#33182194

2018/05/06(日) 20:28:51.95

>>229
他の環境はそんなに安定してるのか？
VSが特別に酷いとは思わないけど。
MSデスってなんでここにいるの？

2018/05/06(日) 20:30:40.96

>>230
俺がいつMSをデスった？いつ他の環境と比較した？
ID:OZSh5wZJ0と間違えなさんな

2018/05/06(日) 20:37:41.43

>>231
Winアプリはオワコンって言ったろ。
それより、CAD作ってみろ、って恫喝的に書いたろ。
あのフォローをしてくれ。論理的に。

2018/05/06(日) 20:39:01.49

>>213
ごめん。
人違いだった。

2018/05/06(日) 20:40:12.87

>>233
たびたび訂正ですがアンカ間違えた。
すまん。

2018/05/06(日) 20:46:08.35

わかりやすく発狂してんなー
初学者どうたら言うんならもっと普及してるもん押すべきじゃあないの?
言っとくけどC#自体は他でも使われてるからなUnityとか

>>229
毎度再現するんでもないからなー
Formでは一回も落ちたことないからXAML関係が比較的不安定なのはそうじゃないの

2018/05/06(日) 20:58:22.97

>>235
見っともないぞ。
昔からいる古狸かも知れないが、もっとちゃんとしろ。
初学者惑わす書き込みを堂々とするのはやめて、自分の考え披露するのは構わないけど。

2018/05/06(日) 21:16:41.42

>>232
だから俺は違うってばｗｗｗ

2018/05/06(日) 21:31:09.89

アンカさえまともに書けないやつがコード書けるのか？

2018/05/06(日) 21:39:39.84

>>237
ごめん。
ちょっと酔っ払って熱くなった。
もうここらで寝ます。
>>238
ご心配いただきありがとうございます。

2018/05/07(月) 11:50:51.85

わたし錯乱某

2018/05/08(火) 02:53:46.31

わい、コンソールアプリしか作ってない

2018/05/08(火) 03:04:56.28

>>241
.NET Core Global Toolsおもしろいよね

2018/05/11(金) 22:56:53.52

フォームアプリケーションで

A.初期設定画面
表示する円の大きさ、数、表示座標の範囲などの初期値を設定

B.ゲーム画面
初期設定画面からAの初期値を取得し、メンバ変数に代入して
円を表示する
円を消去する
円の当たり判定をする
などの3つぐらいのメソッドで使用しています。
Bのコードが長くなって200行ぐらいになると、
メンバ変数をどこで使ってるのか全部見なければいけないのは
可読性が悪いのかなと思うようになってきました。
3つのメソッドそれぞれのグループ変数として
それぞれ3つのメソッド内でAの初期値を見に行くコーディングをしたほうが良いのでしょうか？

メンバ変数の方が冗長性はないけど可読性が低くて、
メソッドないのグループ変数にしたほうが冗長性が高いが可読性も高い気がします。

独学でコーディングしているので、お仕事でプログラミングされている方のご意見を伺いたいです。

2018/05/11(金) 23:05:04.79

>>243
Aが入出力と, モデルのデータ保持という3役を担っているのが良くない。
出力が本業なので可能ならばそれに特化するが, 差し当たってはデータ保持を分離して別クラス(モデル)に切り出す

2018/05/12(土) 08:19:23.20

Aは
public int GetTimeLimit
{
bool resultOfGetTimeLimit = int.TryParse(this.timeLimit.Text, out int timeLimit);
if (resultOfGetTimeLimit)
　　return timeLimit;
else
return 0;
}

が10個ぐらいあるだけで、Aの可読性はいいのですが。

Bのクラスから→Aのインスタンス生成→フォーム表示しているので、

Bが
1. Aからの初期値取得
2. 取得した初期値でゲーム画面表示
3. ゲーム中の処理
4. スコアデータとAの初期値テキストファイルへの書き出し

という4つの異なった処理（特に2,3のコードが長い）をしているのと、
Aのコードの量も400行近くになっているのが可読性低下の原因かと思います。

2018/05/12(土) 08:19:38.98

Bの別のクラスを作って分離させたいんだけどBからAのインスタンス生成しているので、
BAの画面処理に基づいた1234はすべてBに入れることになってるんですよね。

これって画面遷移が良くないってことなのかなぁ？

一般的に1234の処理を一つのフォームクラスに押し込んでクラスメンバ変数10個程度、
400行のコードって可読性の観点から許容されるものなんでしょうか？

チームでプログラミングされているプロの方の意見をお伺いできればと思います。
（長文本当に申し訳ありません）

2018/05/12(土) 08:45:11.14

人の話聞いてないねｗ
じゃあもう好きにしたらいいと思うよ

2018/05/12(土) 09:11:24.66

>>247
私の説明か理解が悪いのでしょうか？

Aは100行未満のコード245のコードの連続なので簡単に読めます。
Bが読みづらいのが問題なので、Aの機能を分離しても解決にはならないような。

BがAが取得したデータ保持とゲーム内でのデータ処理の二つを担っているのがまずいとのご指摘であれば、
それはそうかと思いますが、データ保持と処理が画面と密接に関係しているので分離し難いというか・・・。

コード全部見せないで質問すること自体に無理があるのかもしれませんね。
すいません。

2018/05/12(土) 09:18:34.84

たぶん端的にこう質問すればよかったのかと思います。

フォームを生成しているクラスのコードが400行、メンバ変数が10個、メソッドが8個、で、
メンバ変数はそれぞれのメソッドで3個ぐらい引用しています。

こういうコードってチームで作業してるプロから見て許容できる範囲でしょうか？
処理が多少冗長になってもメンバ変数を少なくして、メソッド内でグローバル変数として定義するべきでしょうか？

2018/05/12(土) 09:19:07.30

>>248
Aを入出力専門のAViewとデータ保持専門のDataHolderに分離
Bをゲーム画面描画専門のBViewと実際の内部処理を行うGameModel, 各種書き出しを行うWriterに分離

Windowのインスタンスの内部で色々な処理を行うのがそもそも間違ってる
描画と変更の通知以外何もさせるな

2018/05/12(土) 10:01:27.82

>>250
ありがとうございます。
理解できました。

フォーム生成するクラスはフォームの描画、変更に特化

A　初期値入力フォームを生成するクラス
B　データを保持するクラス
C　ゲーム画面表示クラス
D ゲームのルールに基づいてBを更新するクラス

分かりやすい。
これがオブジェクト指向ってやつか・・・。

2018/05/12(土) 10:07:34.76

自分は成り行きでBの機能の一部をCに放り込んでしまったから、
Bを処理するDも必要に迫られてCに入れざるを得なくなってたんですね。

入門書にあったサンプルプログラムはコード数が少なかったから、
BをCに入れてるものが結構あったので無意識にこんなもんだと思ってました。

こういうのって本では学びづらいですね。
勉強になりました。
ありがとうございます。

2018/05/12(土) 11:04:14.67

>>251
それはOOPではなくMVCな。一応。