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/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な。一応。

2018/05/12(土) 11:05:17.79

まぁGUIアプリケーションでのOOPの具体的なアーキテクチャだから

2018/05/12(土) 11:23:13.92

MVCは初耳で今ググって勉強しました。

やはり自分のコードは人と共有できるレベルではなかったですね。
MVCの設計で修正してみます。

手続き型言語しかやってないので、
手続きで処理していって
「なんども同じ手続き出てくるな。」
と思ったらクラスにして分離する思考になってたんですけど、
それじゃだめですね。

こういうのが学べるいい本があったらいいなぁ。

2018/05/12(土) 11:32:37.31

dataHolderクラスってABCDどれからもアクセスすることになるんですが、
パブリックにして、どこからでも読み書きできるようにしていいんでしょうか？

バグの温床になるからダメ？

2018/05/12(土) 11:36:18.82

マイクロソフトのホームページだとPublicにしてますね。

これだとどこからでもすべてのデータにアクセスできるから便利だし可読性もいいけど、
どこかでうかつにdataHolderの変数に変な値を入れると、
どこがバグになっているのか全コード読まなければいけないですね。

うーん・・・。
世の中そんなもんなのか？

2018/05/12(土) 11:43:38.40

>>256
お好きに
結局は書きやすさと安全性のトレードオフ

ガッチガチに書くならgetterだけのImmutableオブジェクトを表すインターフェイスとそれを実装する具体クラスに分離してViewにはインターフェイスだけ教えるとか(あまりやらない)
作る人数とか規模によってどの程度強制するか変わってくるから程よくやるのが重要, 一貫性は重要だが徹底しすぎるとしんどい

2018/05/12(土) 11:57:15.21

>>258
immutableなんてものがあるんですね。
ごく一部の変数以外はimmutableで事足りるから、immutable設定にします。
publicでdataHolderクラス作ってメンバ変数はすべてimmutableにすれば、

可読性、コーディングの利便性、安全性

全部満たせますね。
なんて便利なんだ…。(　ﾟдﾟ)

2018/05/12(土) 12:02:17.65

>>259
残念ながらC#では上手くImmutableに出来ない(出来るかもしれないが最近やってないので詳しい人教えて)
TypeScriptとかなら既存の型にReadonlyを再帰的に付けた型が簡単に作れるんだけどなぁ

2018/05/12(土) 12:04:38.53

MVCって、VとCの境界が曖昧になりがちだよな。
ってか、VとCを分ける様な事するからUIが使い辛い物になるんだよな。

2018/05/12(土) 12:06:20.36

>>261
せやな
MVVMとかあるしな

2018/05/12(土) 12:12:09.32

そそ、MVCやMVPってのは、オンラインサービスみたいにデータ管理と画面操作が隔離してる様なコンピュータサービスでなら適してるけど、スマホとかパソコンの中で完結した操作性重視のアプリの設計には適して無いんだよな。

2018/05/12(土) 12:25:35.08

厳密に言えば readonly と immutable は別
interface で表現出来るのは readonly

2018/05/12(土) 12:57:15.57

残念・・・

bool resultOfGetTimeLimit = int.TryParse(this.timeLimit.Text, out constant.timeLimit);

みたいに定数をフォームから取得できればありがたいんだけどなぁ。
そういう需要ってあんまりないんだろうか。

2018/05/12(土) 14:45:46.09

>>265
何いってるのかわかりません

2018/05/12(土) 14:55:22.20

それに変数名長すぎ

2018/05/12(土) 14:55:53.42

しかもbool型に見えない

2018/05/12(土) 17:01:44.57

なんかもうMVCに従って書き直すの不可能な気がしてきた・・・
初めから作り直すほうが早いかも・・・。

2018/05/12(土) 17:16:54.39

>>269
MVCは基本的にWebだかんね…

2018/05/12(土) 17:19:31.54

設計思想根本から変えるのに小手先の修正で済むわけないよｗ

2018/05/12(土) 17:32:27.30

初心者が勉強のためにゲームプログラムを作るのにMVCなんてナンセンスです。
先ず、何でもいいから動くものを作る。プログラムスタイルはそれからいろんなな本で学べばいい。

2018/05/12(土) 17:33:18.63

まず設計からやり直さないと無理だと思うよ

2018/05/12(土) 18:06:22.88

頭の中がどぁーっとなってきました。
とりあえずゲーム本体は完成したんですが、一部改変しようとしたらかなりの機能がすべてゲーム画面フォームにくっついてるので読みづらいことこの上ないなと。
データ部分を別構造にしたかったんですが、ほぼ句見直しに近い改変であたまがわやになってます。

2018/05/12(土) 18:11:39.59

すんごい読みづらいコードなんだけどこのまま進めていいのかな・・・。
とりあえず力業で進めることは可能なんですけど気持ち悪い。

2018/05/12(土) 18:12:38.37

>>274
で、でたーオブジェクト指向不出来form.cs全部書込奴w

2018/05/12(土) 18:16:14.33

動くコード書ける奴の方が神だからな。
設計どうのこうのなんて、動くコード書ける様になってから理解すれば良い。
何なら作った後で反省的を挙げながらここはこう言う構造の方が良かったんじゃね？
なんてやるのが一番設計の知識ぐ身につく。

2018/05/12(土) 18:23:40.04

自分のプログラムが汚いわかりにくいと思ったのなら、あなたはセンスがあるんだよ。
汚いプログラム書いて平気なプロもいるからね。
後はいろんなサンプルプログラムを検索して読んだらいい。あっ、これがいいとか気付きがあると思う。

2018/05/12(土) 18:26:39.51

プログラマの能力を試すには書かせるより読ませるのがいいからね。
人のプログラム読めない奴は進歩ないから。

2018/05/12(土) 18:31:48.49

あれ、根本的なことが分かってないことが分かりました。

B　DataHolder
C ゲーム
D　スコア記録

CからBのインスタンスを生成
DataHolder dataHolder1=new DataHolder();
すればCのpublic変数aにアクセスするときはdataHolder.a=hoge;とかでいいけど、
DからBのdataHolder1の変数aにアクセスってできるんですか？

CからDにdataHolder1の参照を渡すってこと？？

2018/05/12(土) 18:33:40.32

>>276
全部ではないけどほぼご指摘あってます・・・。
本に書いてある小さなプログラムはほとんどform.csに放り込んでたので、そんなものかと思ってた。

2018/05/12(土) 18:34:30.46

>>277
ありがとうございます。
今ようやっと設計の大事さを学習しました。
レベル0から0.01ぐらいには成長できた気がします。

2018/05/12(土) 18:35:15.53

>>280
そもそもこれが分かってなかったから一つのフォーム画面にいろいろ機能を盛り込みすぎたんだと。

2018/05/12(土) 18:37:29.64

>>280

間違いました。

あれ、根本的なことが分かってないことが分かりました。

B　DataHolder
C ゲーム
D　スコア記録

CからBのインスタンスを生成
DataHolder dataHolder1=new DataHolder();
すればCのpublic変数aにアクセスするときはthis.a=dataHolder.a;とかでいいけど、
DからBのdataHolder1の変数aにアクセスってできるんですか？

CからDにdataHolder1の参照を渡すってこと？？