ふらっと 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

2017/07/02(日) 16:08:18.93

普通using使うだろ

2017/07/02(日) 16:41:39.44

そういえば、使い終わったオブジェクトは using 使うなりして破棄してね。
ってリクエストしたら、try - catch の finaly で .dispose するからいいんだって言った人がいたな。
結果は同じだけど、どうせ直すなら using の方が素直な気がしたんだけど。まあいいけど。

2017/07/02(日) 16:50:21.19

>>608
usingの複数定義が気持ち悪いと言って頑なにfinalyでdisposeする人居たわ

2017/07/02(日) 16:51:54.15

>>607
開放されるかどうかは作り手の努力次第だけどなｗ

2017/07/02(日) 16:57:16.82

なんかくせーなお前
技術的に風呂入ってる？

2017/07/02(日) 16:57:31.53

>>609
シコシコ

2017/07/02(日) 16:59:16.69

他人の作った関数が仕様通りに動作するかどうかはその作り手の努力次第、ってのと何か違うの？

2017/07/02(日) 17:19:56.91

>>611
ｳﾙｾｪｿﾞﾎﾗｧ!( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ

2017/07/02(日) 17:26:36.02

>>610
そんなの using 関係ないだろ
自分のなけなしの知識全開かよ w

2017/07/02(日) 17:43:52.22

>>615
でもdisposeなら解放されるんでしょ?

2017/07/02(日) 18:49:49.73

>>616
はあ？
using って単なるシンタックスシュガーだぞ

2017/07/02(日) 19:18:19.40

>>617
(￣ー￣)ﾆﾔﾘ

2017/07/02(日) 20:12:27.11

>>593です
レス頂いた皆様ありがとうございます
listの追加はインスタンスの作成と同時に行いlistから削除した後は2度と使用しません
そのクラスは個別のデータを管理するだけのクラスです
とりあえずあまり何も考えずGCの対象になると思い明示的な解放は必要ないのかなと思ってたのですが作法的にどうなのかと思い確認しました
ですので現状IDisposableは実装しておらず言わばリストから削除してほったらしの状態です
GCについてはあまり勉強していないので調べてみたいと思います
その他アドバイスありましたらよろしくお願いします

2017/07/02(日) 21:55:59.98

>>606
そんなコード書き奴いるのが驚きだけど、居るところにゃ居るんだなぁ。。。

2017/07/03(月) 07:19:58.02

>>620
> Diposeしてるやつ使おうとしたりremoveatしてるやつをremoveatされてないかのように使ったりして死んでる
これGC関係ないし
> 後はマルチスレッド関係で削除してんのに別スレッドではそうでないつもりで動いてたり
別スレッドだろうが参照もってりゃ回収されないし
どう見てもおかしい人だから相手しなくていいと思うよ

2017/07/03(月) 09:45:56.42

数日前からいるガイジだな

2017/07/03(月) 10:16:25.45

>>621
強制ガベコレすると落ちるけどしないと落ちないときあるじゃん
ってまあヘンテコなコード書いてないとお目にかかれないけどさ
そんなことないと主張するなら別にそれでもいいよ
俺は困らないし

2017/07/03(月) 12:07:19.95

そうか困らないかよかったなおめでとさん

2017/07/03(月) 13:36:19.21

Visual StudioC#
同じ階層のフォルダをクリックしたら、設定を変更してメモ帳を起動でませんか？

構造
フォルダ0
ーーフォルダ1
ーーメモ.txt

フォルダ1をクリックしたら、同じファイルのメモ.txtを太字にして、
閉じる時に元に戻す。

2017/07/03(月) 13:37:07.82

>>625
太字にして起動でした。

2017/07/03(月) 13:50:01.76

すいません。
どうもテンパってる見たいです。

フォルダを開くと同時にメモ帳でフォルダ内のテキストファイルを全て起動
メモ帳を起動する前に　太字とファントにして文字サイズを変更したい。
メモ帳を閉じたら、設定を元に戻す

どうしたら良いでしょうか？

2017/07/03(月) 15:16:40.85

落ち着け
フォルダをクリックしたらってのはエクスプローラ上でってこと？

フォントはメモ帳開く前にレジストリ変更、開いたら戻すって感じでできると思う

2017/07/03(月) 15:23:47.15

>>628
エクスプローラーの右側に有る奴です。

2017/07/03(月) 15:58:34.40

やゃ落ち着きました。

アクティブフォルダ（操作中のファオルダ）内にtxtファイル存在するか調べる。
もしも、存在するなら、Windows10のメモ帳で全てのtxtファイルを開く。
存在しないなら、何もしない。

メモ帳を開く場合
　　　　規定フォントかを調べる。
windows10付属の規定フォントで無いなら、規定フォントにする。
＿規定フォントなら、文字を大きくする。
＿次に太字にする。

メモ帳の開く場所をディスプレイ中央に設定する。

やりたい事はこんな感じです。

2017/07/03(月) 16:05:48.40

>>601
Zombie

2017/07/03(月) 17:26:05.31

>>630
アクティブフォルダを検知する手段が見当つかないけど
それをドロップされたフォルダ（指定されたパス）で実行するに変更ならすぐできるんじゃない？
１．指定されたディレクトリに*.txtがあるか調べる
２．見つかればメモ帳の設定をバックアップして変更>>628
３．メモ帳に*.txtを順次渡して起動
４．メモ帳が全て終了したら設定を元に戻して終了

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 17:40:07.28

>>632
アクティブフォルダを検知する方法はボクも知らないです。

タスクバーに存在するフォルダがアイドル常態かどうかを調べて、
アクティブなら実行させる　とか考えました。

一日、数百回ほど、
フォルダを開くのに対してドロップ＆ドラッグは流石に勘弁して下さい。

2017/07/03(月) 17:43:31.54

>>633
じゃあフォルダ群を最初に全部登録して選択したもので実行するとか
とりあえず>>632の部分は必要になるから答えを待ちながら作った方がいいんじゃないかな

2017/07/03(月) 17:52:47.65

俺にはウィルスにしか見えないわけだが
こいつの目的は何なの?

2017/07/03(月) 17:54:07.35

DOSじゃないんだからOS全体でアクティブなディレクトリなんて存在しないと思うよw

2017/07/03(月) 17:55:34.21

アプリケーションにドロップしたディレクトリじゃ駄目なのかよ

2017/07/03(月) 18:00:01.58

まず現行業務フローの洗い出しができてないよね
１日数百回フォルダ移動してる暇な奴ってすでに俺には聞き込み調査か粛清が必要なレベル
プログラムを組むんじゃなくて
ローキックの連打で解決できそうな臭いしてる

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:14:18.18

皆さん、いろんな意見をありがとうございます。

（笑わないで聞いて下さい。）
毎回落としてくる、エロ画像がボクの宝物なので、
大事にパスワードを設定してます。

開く時にパスワードを書いたメモファイルを何時も開き忘れるので、
フォルダを開いたと同時に表示して欲しいんです。

>>638
画像によっては属性が夢の様に、いっぱい詰まってるので毎回、移動させてます。

2017/07/03(月) 18:16:39.30

エクスプローラーもメモ帳も自分で作ればいいだけに見えるんだが・・・
それらの部品ならCodeProject漁れば出てくるよ

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:17:23.61

フォルダにパスをかけなければと言う人も居ますが、フォルダにパスワードは必要です。
メモファイルは隠しフォルダにしたら何とか隠せますが、パスがついてない画像は
閲覧されちゃいます。

2017/07/03(月) 18:24:04.65

>>640に賛成
ディレクトリの位置に紐つけたパスワードのデータベース作ればメモ帳起動する必要もなくなる

2017/07/03(月) 18:28:02.02

>>623
> 強制ガベコレすると落ちるけどしないと落ちないときあるじゃん
>>605みたいなケースだろ
そうじゃなくて普通に使っててそんなことになると言うならサンプルコードあげてみそ

**652** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:34:05.18

>>642
メモ帳が必要な理由としては、コメント書いてるんです。
「今日も可愛いね」「その猫耳が似合ってるよ。」とか書き込んで、
後から同じファイルを開いた時に追加してコメント入れてるんので、メモ帳を起動させたいのです。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:35:12.16

間違えました。
652では無く、
625でした。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:46:56.71

現状では634の方法で行きたいと思います。
一部を保留にしながら、632にを参考に進めて行きたいと思います。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 20:33:26.13

レジストリを触りたくないので、メモ帳を起動後にフォントと文字サイズを変更
しようと思ってますが、やり方が見つかりません。

ファイル内に.txtが有るか調べる
ファイルを指定してメモ帳で起動するまで行きましたが、
起動後、メモ帳の設定の仕方が分かりません。
どなたか教えてくれませんか？

（ファイルへの書き込みと読み込みは結構、でてくるんですけどねｗ）

2017/07/03(月) 21:08:48.55

DLL AとAが参照しているDLL Bがあって、BでAのPOCOクラス使いたいんだけど循環参照になっちゃうからPOCOクラスをDLL Cとか別で定義するしかないよね？
C#なら別DLLにしなくてもいけると言われたんだが、どうやるのか見当つかない・・・

2017/07/03(月) 21:10:48.36

メモ帳だから出来ないんよ。
最低限テキスト編集機能しか無いからね。
ワープロじゃ無いから、テキスト編集さえ出来れば良い(高機能でも快適な編集が出来ればいい)ってのがテキストエディタ。
フォントとかはワープロの領分だよ。

2017/07/03(月) 21:11:02.19

>>648
Bに実装してAから呼び出す

2017/07/03(月) 21:15:30.82

>>648
AとBを一つのDLLにまとめる
どうせ切り離せないなら分ける意味ないでしょ

2017/07/03(月) 21:19:23.58

>>649
メモ帳にフォントと文字サイズの指定はあるぞ。
表示される文章全体に対してだが。

2017/07/03(月) 21:21:13.75

あったっけ。
ま、どうでも良いけど。

2017/07/03(月) 21:29:33.51

指定じゃ誤解を招くな。
そういうアプリの設定ね。

2017/07/03(月) 21:31:35.49

>>648
そうするしかない、というよりそうすべきだね。
俺は共通のenum一つのために別のdllに分けたことがありますw

2017/07/03(月) 21:34:16.70

>>650>>651>>655
やっぱり今のままじゃどうやっても無理だよね、サンクス

2017/07/03(月) 21:37:08.97

循環参照が発生した時点で設計バグなので楽しいリファクタリングタイムだ

2017/07/03(月) 21:52:41.27

んでまた資料も書かずに突貫工事でプログラム組んで余計ややこしいことになっちゃうまでが準備体操

2017/07/03(月) 21:57:30.38

あらゆる管理業務の負荷はコードの品質で天地の差が出る
循環参照してるようなクソコードのドキュメンテーションは地獄だ
リファクタリングしてからやった方がいい

2017/07/03(月) 22:01:47.75

そのリファクタリングが正しく出来なさそうだからまず資料作れって言ってんだよハゲ
っていう不毛な会話はもうしない
突貫工事が好きなところといい
きっと彼は土属性に違いないのだから

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

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