ふらっと C#,C♯,C＃（初心者用） Part129 [無断転載禁止]©2ch.net

2017/06/09(金) 18:36:01.72

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。

他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。

内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。

なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

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

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part128
http://mevius.2ch.net/test/read.cgi/tech/1493730340/

■関連スレ
C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1492843013/

■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
---

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

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 22:32:44.15

てっきり無視されるかと思ってました。ｗ

フォルダを開くのを認識させるのは、どうしたら良いのでしょうか？
指定したフォルダを開く事はできても、これから開くフォルダを認識する事なんてできるのでしょうか？

質問ばかりで申し訳ないです。

2017/07/03(月) 22:35:33.59

>>656
よろしくないってだけで、無理ではないと思うが。

2017/07/03(月) 22:40:33.08

>>660
正しいドキュメントを書くことはコードを書くことよりはるかに難しい
循環参照するような破滅的コードが相手だとまともなドキュメントを工数に見合う時間で作れる見込みは少ない

そもそもコンパイラや静的解析ツールを利用して体系だった機械的なプロセスでコードの品質を高めて可読性を上げることができる
それがリファクタリングの中でも大きなメリットの１つだろ
そこへ来てドキュメントを書いてからリファクタリングなどというのは全く見当違いの馬鹿馬鹿しい行為なんだよ

ドキュメントを作るのはリファクタリングで整理されてドキュメント化可能な状態になってから
あるいは探索的リファクタリングで得た知識を忘れないようにドキュメント化する
なんにせよコードを弄った後の話だ

こんなこと普段からコードを書いてリファクタリングしてれば知識がなくとも体感的にわかることなんだけどね
この業界はコードを書かない自称エンジニアさんばかりでため息が出るね

2017/07/03(月) 22:42:41.27

>>663
せめて問題点がわかる粒度の表にするべきだと思うわ

2017/07/03(月) 22:46:38.52

>>663
お前、ドキュメント書いてからソース書いたことないな

異なる文化を持ってる会社と仕事したらボコボコにぶっ叩かれるな
設計書を完璧にfixしないとソースコード触らせてもらえないとこあんぞ
でも一度はそういうところに行くべきだと思う
きっと違った世界が見えるはずだ

2017/07/03(月) 22:50:03.47

どうでもいいよw
それ以上はチラシの裏に書いてよw

2017/07/03(月) 22:51:34.84

スタンダードはv字開発の方なんだけどな

2017/07/03(月) 22:58:15.68

リバースエンジニアリングは小規模でのみ通用する方式

2017/07/03(月) 23:06:11.28

>>664
リファクタリング対象を選ぶために、という理由でなら資料を作る意義はあるかもしれない

例えば複雑度、更新頻度、バグ密度などリファクタリングをする価値を判断できる数字というのは結構、ある
殆どのデータは自動収集できるものでレポートを手作りすることはないだろうが
ざっと目を通した時の難易度などは手作業の方が早いかもしれないね

でもね、リファクタリングの方法を探るために先に資料を作るというのは、ない
制限時間付きのパズルを解こうとしているのにまずはドキュメント？冗談でしょう
やるとしても、パズルを弄りながらメモ書き、程度でしょ

2017/07/03(月) 23:24:27.65

>>669
もうそれ設計でもなんでもねーじゃんｗ

2017/07/03(月) 23:24:29.30

>>665
ガラパゴスの国だからね
文化の違いは認めるよ
修正は設計書のレビューを通してからコーディングという現場に居たこともある
しかし徹底的なドキュメンテーションが正解だとは思わない
ドキュメンテーションには時間がかかるし統一的な記法も機械的な検証方法も無い
実際の挙動を決定するコードと同期しているか定かでは無い
何よりこの手の現場ではコードを弄るという探索的プロセスを軽視する傾向が強いことが問題だ

コードを弄らずにドキュメントだけ正しい状態に持っていこうとするということは
まるでパズルを頭の中で組み立てて手順を資料化するような馬鹿馬鹿しい行為だ
パズルに挑戦する人は誰だって自分の手でパズルを弄りながら考える
それと同じでリファクタリングの方法を考える人は自分の手でリファクタリングをしながら方法を考えるんだ
手を動かす前に思いつくようなアイデアはいつだって陳腐で使い物にならないものばかりだ

2017/07/03(月) 23:28:02.84

完成するかどうか分からんパズルと仕事をおなじにされてもなぁ

2017/07/03(月) 23:32:35.22

肉体言語の使い手だよね
メラ!（右フック!）

2017/07/03(月) 23:39:08.40

>>670
そもそも設計ってなんだと思う？

俺はビルドを実行する前までのプロセスが設計だと思う
コーディングは設計フェーズでコードは設計書
製造はビルダーの仕事

俺らが作るものは最終的には動くプログラムなんだよね
それでコードはそのプログラムがどういう仕組みでどういう風に動きますっていう定義をずらずらと書いたものだよね
それってまさにプログラムの設計書じゃないか

じゃあ世間の言う設計書ってなんだって話だけど
俺からするとそういうのは設計概要とか設計方針の方がしっくりくるんだわ

2017/07/03(月) 23:41:12.61

どっちのいいぶんもまぁわからんでもないが結局プロジェクトの規模によるんじゃないの？
みんなだいたい一人どれくらいのプログラムの量かくの？

2017/07/03(月) 23:41:26.60

宣言型言語で書くならそうだが、普通コードは命令書であって設計書じゃない。

2017/07/03(月) 23:42:46.19

>>673
もう投了ですか？

2017/07/03(月) 23:49:00.34

>>674
いやぁさすがにそれは詭弁にしか聞こえない
だってお前のは材料数も期間もなんもでねーじゃん
ただ単にパズルが解けるまで遊んでるだけで最悪なんの成果もないわけじゃん

2017/07/03(月) 23:51:24.33

>>676
世の中の多くの設計書が手続き(命令)的な書き方をされてますよね
年配のCOBOLエンジニアさんが書く設計書などがまさにそうですが
あれは設計書ではなかったと

2017/07/03(月) 23:52:11.27

だいたいリファクタリングとか言ってるけど
ここまで来てそんな問題起きちゃうのはただの設計ミスだよね?
設計書から完成させる文化の仕事受けて１回軍法会議にかけられて死ねばいいよ

2017/07/03(月) 23:53:02.74

ひとつの型が唯一解とは思わないが設計書は必要だよ
コーディング以降は各テストレビュー完了毎にメンテナンスするくらいの頻度でいい

アルゴリズムの伝達にプログラム要素は含まれない

2017/07/03(月) 23:59:24.25

>>678
現実的な時間で終わるかどうかの見極めはコード弄ってればすぐにわかるよ
むしろコード弄らずにドキュメントベースで話を進めると簡単だと思ったら実は思ったより時間かかりました～なんてことになる
悲しいけど世の中そんなプロジェクトで溢れかえってるのが事実なんだ

2017/07/04(火) 00:00:45.70

>>679
COBOLの設計書ってコード設計という名のコーディングシートを除けばわりと宣言的だぞ
関数型に近い

2017/07/04(火) 00:00:55.20

>>680
断言するけどそんな設計書はありません
就職すればわかるからそのあと出直してきな

2017/07/04(火) 00:03:06.32

>>682
それを外したからリファクタリングなんて名前の設計ミスの修正をやってるように見えるんだが?

2017/07/04(火) 00:10:19.18

>>681
概要を素早く把握するには設計書はちょうどいい文書だと思う
しかし概要を超えた明細はコードで語るべきだ
コードを直す前に必ず設計書修正しろなんてパラノイア的なやり方は負担を増やすだけで利益は少ない
コスト意識のない完璧主義者に付き合わされるのは苦痛だ

2017/07/04(火) 00:14:55.81

>>683
そうなのか
うちのCOBOL経験者はJavaのようなOOP言語でもコテコテの手続き的な設計書を書くよ
まあ人によるってことだろうね

2017/07/04(火) 00:16:28.89

>>686
テストレビュー完了毎にメンテナンスするって意味がうまく伝えられなくてすまん
修正毎とか時間と人件費の無駄、やってらんねーっすよってこと

俺にとっての設計書ってのはほぼテスト仕様書
詳細設計＝単体テスト
概要設計＝結合テスト
要件設計＝統合テスト

2017/07/04(火) 00:21:53.60

>>685
どんなに慎重にやっても設計ミスは出る
そもそも仕様そのものが業務の変化に依存している以上不変ではない
完全な設計書などこの世界には存在しない
設計書の間違いを検証する手段がないので設計書には間違いがないと勘違いする人が居る
設計ミスではなくともリファクタリングを行うことが多々ある

2017/07/04(火) 00:24:42.89

>>686
いやーさすがにテキストボックスが右詰めか左詰めかとかまで書かせるのはキチガイだと思うけど
全体の大まかな構造までしけちゃってるのを見ると流石に見逃せねぇ
ってところじゃん?
しかもそこからの対応もパズルとか言って用は動くまでブラウン管テレビぶん殴ってるババアと大差ねぇなと
これはねぇキミ、プロのやるこっちゃないよ

2017/07/04(火) 00:27:36.58

プロがこんなところでしょうもない揚げ足取りの議論なんかするかw
ばっかじゃねえのほんっと

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/04(火) 01:07:42.92

色々考えましたが、解決法が見つかりませんでした。
どなたか、何か良い案は有りませんかね？

2017/07/04(火) 01:17:30.16

エクスプローラーっぽいアプリを自作した方が楽だと思う。
メモ帳にしたって、アプリにテキストボックス埋め込んで表示すれば足りそうだし。

2017/07/04(火) 01:28:43.92

>>692
エロ動画を見ればいいんじゃん?
大半のエロ画像なんてゴミになるよ

2017/07/04(火) 02:03:27.54

nameofって短縮系の名前しか得られないの？
名前空間とかそのまま欲しいな

2017/07/04(火) 04:20:45.13

伸びてる時は

2017/07/04(火) 07:32:18.26

動的にはtypeof(...).Namespaceやらで取れるからそれで十分って判断じゃね
文字列で完全限定名が取れて嬉しいケースってあんまり思いつかん
属性で型名を指定するのはコンパイル時に型を参照できないからなわけでそこでnameofは使えないし

2017/07/04(火) 07:44:04.75

>>690
故障したテレビを外から眺めながら中身のことを妄想して原因はあーでもないこーでもないと議論するのが設計書文化

とりあえず安全確保はしておいてから、テレビを分解して内部構造を調べ、故障原因を理解し、原因を取り除いたり、より良い構造になるように努力するのがコーディング文化

どちらが有意義な仕事をして居るかは一目瞭然だね

2017/07/04(火) 08:55:00.74

>>698
でも仕組みわかってないんだろ？
触んなよｗ

2017/07/04(火) 10:52:33.77

>>698
技術力とちゃんとした設計書があれば、妄想じゃなくて起こりうる原因を挙げれるわけだが
妄想レベルの設計書しか書けないから有意義な仕事が出来ないんじゃない

2017/07/04(火) 19:27:22.44

C言語やC++やJavaを学んできたけど、C#が一番難しいです
こういう方居ますか？
また言語の難易度はどのようなものなのでしょうか

2017/07/04(火) 19:30:26.44

>>701
どういうところが難しいと感じますか？

2017/07/04(火) 19:31:23.02

むしろC++の何を知ってるのか聞いてみたい

2017/07/04(火) 19:32:43.87

>>702
競技プログラミングをC#でやりたいんですけど、C++と比べて難しいです…
難しいと思うのは、一番は全体像が多すぎて掴めないです

2017/07/04(火) 19:35:23.49

>>704
競技プログラミングなら、C++でいいんじゃ……

2017/07/04(火) 19:41:30.05

全体像が多すぎて掴めないってなにさ。競技プログラミング向きではないとおもうが。

2017/07/04(火) 19:42:09.30

>>703
昔はゲーム作ってました
今はunityでゲーム作ろうと思ってるんですけど、他のこともやってみようかな？って感じです
>>705
C#で書いてた人がかっこいいと思ったので…

2017/07/04(火) 19:47:44.39

>>706
自分でもわからないです
まだ触り始めたばっかだから色々作ることにします…

2017/07/04(火) 21:21:54.56

難しいと感じるところもあるかもしれないけど
いいところもいっぱいあるでしょ？

もうプロパティがない言語触りたくない

2017/07/04(火) 22:05:02.40

>>709
良いところもあるけど、色々作って試行錯誤します

2017/07/04(火) 22:05:31.08

>>709
プロパティは確かに便利ですね

2017/07/04(火) 22:09:38.11

慣れてくるとあんまりプロパティ作らなくなるけどね
C#初心者はWinFormsとかの「お客さん向け」設計を真似してプロパティを大量に作りがち
次第に整合性を重視するようになると自然にプロパティは減っていく

2017/07/04(火) 22:20:04.96

自然にプロパティが減ってく人でも皆無にはならない程度には便利だということ

2017/07/04(火) 22:22:09.64

>>712
良く分からん。
整合性を重視するってどういうこと。

2017/07/04(火) 22:27:37.54

お客さん向け設計ってのもわかるようなわからんような。

2017/07/04(火) 22:37:51.95

自分だけが気づいた何かがあると思いたいお年頃なんでしょう
ネットde真実の一種だねw

2017/07/04(火) 23:06:36.69

>>707
たまに競技プログラミングやるけど、スラスラC++書ける人格好良いと思うなぁ。

格好良さはさておき、C#で難しいとこってなんだろ？　デリゲート型とか？

2017/07/04(火) 23:22:54.20

>>714-715
プロパティを正しく公開するのって結構大変なんだよ
内部で生じた一時的な変な状態を外に見せないようにしたり、
常にプロパティの値が外から書き換えられることを考慮する必要があったり
不特定多数の人に便利に使ってもらうためのクラスならそこに手間をかける価値はあるけど、我々が作るクラスのほとんどはそうではない

2017/07/04(火) 23:28:02.70

プロパティを使わない（フィールド直公開？メソッド？）ことで問題が回避されるんじゃなければ
何言ってるのか意味不明だね

2017/07/04(火) 23:28:07.57

公開されてるからいつでも触っていいのかと思ったら
initの前だけかよって?

2017/07/04(火) 23:29:50.21

なんの注意書きもないから1ミリ秒単位で更新してたら死にやがったよコイツ的な?

2017/07/04(火) 23:32:37.20

update()するたびに使用メモリが増えて行くのは仕様ですか?

2017/07/04(火) 23:32:49.21

>>719
プロパティに限らず、余計なメンバを公開しないほうが楽だと言ってるだけだよ

2017/07/04(火) 23:34:22.56

アンカ付けたんなら「お客さん向け設計」の説明もしてくれよ。

2017/07/04(火) 23:36:17.05

>>723
語るに落ちてるじゃんw

要するに、それは上手にカプセル化して安全で使いやすいブラックボックスを作りましょうってことであって、
プロパティに限った話じゃない

2017/07/04(火) 23:37:40.88

お客さんは開発者だろ?
マイクロソフトが開発者向けに用意したコントロールと
うちらが仕事で仕様を満たすために作るものとは手間やクオリティが全然違うってことだろ

2017/07/04(火) 23:39:13.52

>>725
その通り。
特にプロパティは初心者が不必要に公開してしまう傾向がある、ということね

2017/07/04(火) 23:40:18.13

じゃあ誰かに公開して誰かに使わせる予定あるのかよ?
って言ったらほとんどないんじゃん?的な?
感じで代弁してみた

2017/07/04(火) 23:54:47.56

>>725
そんな傾向あるかね？
自動プロパティ限定の話ならわかる気もするけど

2017/07/04(火) 23:55:16.97

そういう話なら、初心者は何でもpublicにしがちだけど慣れてくると
適切なアクセス修飾子を使うようになる、とか言わなきゃ。

でもこれってそんな気張って言うような話じゃなくて、初歩の初歩の話だよねw

2017/07/04(火) 23:56:43.86

安価みすってた>>727ね

2017/07/05(水) 00:01:10.61

整合性を重視って妙な言い回しするから何かと思ったら…

2017/07/05(水) 00:40:08.75

初心者スレだよ

2017/07/05(水) 12:46:25.76

初心者が質問するスレな
初心者がプロパティガーって知ったかするスレじゃない

2017/07/05(水) 17:00:46.07

https://youtu.be/3MBQtuK2nZ8
これやってるんですけど乱数入れると2行目のレベルの数字がバグってしまいます
原因が全くわかりません
助けてください

2017/07/05(水) 17:25:23.39

そういう丸投げの質問にわざわざ回答してくれるお人よしがいるかもしれないと
思えるところが凄い

2017/07/05(水) 17:32:08.14

>>735
動画主がソース公開してるみたいだから自分のと比較してみたら？

2017/07/05(水) 18:14:22.85

お騒がせしました
公開されてるソースと比べたところ、違いは勇者の名前と勝手に追加したゴールドの乱数だけでした
結局String name ="";の行を弄ったらバグらず表示することができました
名前の文字数が5文字以下だと文字がバグりました

2017/07/05(水) 18:20:17.61

5文字ではなく4文字以下で数字がバグるでした

2017/07/05(水) 21:34:50.46

それ動画主もクソやんか。
どこがどうクソなのか自分で理解出来るようにしなよ。

2017/07/05(水) 22:04:55.79

役立たずの口だけ番長は黙って死んでろゴミカス
てめえみたいな奴が初心者スレを腐らせんだよ

2017/07/05(水) 22:36:26.64

ササクッテロリって初めて見たww
どうでもいいけど

2017/07/05(水) 22:37:44.89

某所のクソコテがササクッテロルだからいつも見てるな

2017/07/06(木) 09:16:24.92

>>738
いきなり中ボスに挑んだなｗ

2017/07/06(木) 09:19:32.16

webbrowserでダイアログボックスを開いて操作することってできるんでしょうか？
たとえば画像アップロードサイトでファイルをアップロードするために「ファイルを選択」ボタンを押すと
ファイル選択画面になりますが、ここにファイル名を自動で入力して自動で「開く」ボタンを押したいと。

外部のブラウザならウィンドウハンドルを取得してそこに投げてやればいいのはわかるのですが、
webbrowserでやろうとして失敗しました。

2017/07/06(木) 09:36:10.51

>>745
webのやり取りは普通は[POST]と言う命令をサーバーに送るだけなので、C#で制御するにはそのページがデータを送る仕組みを解析して
同じようにデータを送る方法があります
そのページで何をやっているのか知るために、ｈｔｍｌとjavascriptの基本は抑えておいたほうが良いよ

2017/07/06(木) 15:47:39.70

今更 var に感動してるんだけど、foreach の中じゃ無理なん？

System.Web.UI.WebControls.CheckBoxList　checkboxlist;
foreach(var list in checkboxlist.Items)
{
　　list.・・・
}

System.Web.UI.WebControls.ListControl 型を類推してほしいのだが、object になってしまう。。。

2017/07/06(木) 15:50:14.08

×　System.Web.UI.WebControls.ListControl 型を類推してほしいのだが
○　System.Web.UI.WebControls.ListItem 型を類推してほしいのだが

2017/07/06(木) 15:54:53.37

そのプロパティが返す型がobject型なんでしょ。キャストすればいい

2017/07/06(木) 16:07:03.45

ジェネリックは.NET 2.0から
System.Web.UI.WebControlsみたいな.NET 1.xからあるものはIEnumerableしか実装してない
IEnumerator.Currentがobjectなのでvarは常にobjectとしか扱えない

2017/07/06(木) 16:10:25.20

msdnみた。
itemsはlistcollectionという型を返すらしい。
それはenumrableを継承した型でジェネリックによる型推論が効かない。
キャストでEnumrable〈型〉を指定すればいけるんじゃないかな。

2017/07/06(木) 16:36:28.81

どうでもいいけど類推って言葉の使い方間違ってますよw

2017/07/06(木) 17:09:22.66

>>747
ﾃﾞｷﾓｼﾅｲｺｰﾄﾞｶｲﾃﾝｼﾞｬﾈｰ
( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ
( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ
( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ

2017/07/06(木) 19:25:03.65

>>746
そのやり方自体はテキストベースではやったことがあるので使い方はわかりますが、ファイルを添付したい場合にどうしたらいいか
知らなかったのでウィンドウ操作のほうでやってみました。
ウィンドウ操作の方法もご存知でしたら教えてください。

2017/07/06(木) 23:14:22.57

var [ ] 配列
こーゆうふうにvarじゃ配列組めないの？

2017/07/06(木) 23:17:58.00

>>755
var (C# リファレンス)
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/keywords/var
varによる変数宣言とコレクション初期化子
varが使用できる場面
http://www.atmarkit.co.jp/fdotnet/csharp30/csharp30_03/csharp30_03_03.html

2017/07/06(木) 23:52:16.07

こういう風ってどういう風だよww

2017/07/07(金) 00:03:47.18

>>755
それじゃ型を推論出来ない。
var piyo = new [] { 1, 2, 3 };
みたいに初期化子込みなら型を省略出来る。

2017/07/07(金) 00:28:42.12

>>754
スレッドを起動する
windowを監視してファイル選択ダイアログを見つける
ダイアログを操作する

2017/07/07(金) 01:41:04.05

ai仕込んで、そろそろ型を推測するようにして欲しい。
ここで数字型の配列使いそうとか