ふらっとC#,C♯,C＃（初心者用） Part92

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 21:32:32.95

ふらっとVisual C#,C♯,C＃（初心者用）

このスレッドは
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からない場合など、勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。

なお、テンプレ2行目が読めない回答者は邪魔なので後述のC#相談室に移動して下さい。

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

関連スレ
ふらっとC#,C♯,C＃（初心者用） Part91
http://toro.2ch.net/test/read.cgi/tech/1335089085/
C#, C♯, C＃相談室 Part71
http://toro.2ch.net/test/read.cgi/tech/1332575004/

こんな感じでソフトウェア板に立てたらどうかな

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:49:38.04

>>7
巣に帰れってことだな。言い返す言葉もないよ。
だが、避難所を同じ板に作ってもしょうがないからな。

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:55:41.61

荒れてる時はこっちに誘導したらいいんじゃないかな

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 22:57:29.91

まあ、あっちに来た質問を無理にこっちに誘導する気はあんまり無いんだ。
向こうでも書いたけど、あっちのスレが回答不能なレベルに達してるってわけじゃないし。
むしろ、「IDがあった方が議論しやすい」と感じた人間だけが、こっちで議論すれば良いと思ってる。

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:07:50.71

こっちを擁護しておいてなんだが、これで本スレのテンプレに
こっちのスレを追加すべき/すべきでない議論とか巻き起こるのは嫌だなあ。
テンプレ周りの変更議論はもめるし。
もめるくらいなら追加したくない。

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:10:39.92

問題は回答者がここにくるかだな

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:11:12.03

俺が一番回答してるから俺がいれば大概大丈夫だろう

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:17:43.49

>>12
俺も一応回答者。どんくらい回答したかまでは覚えてないけど。

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:34:02.35

じゃあ、ちょっと質問
インターフェイス使うと改変に強いっていうけどプロパティとどう違うの？
プロパティも内部の構造変えても他のクラスに影響がない
影響が出るとしたら、プロパティの型を変更した場合
インターフェイスも引数の型変更したら結局使いものにならないし
改変に強いって説明の仕方おかしくない？

内部の違うクラスを同じようにアクセスできるのを明示するということならわかるけどね

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:43:32.60

クラスというのは、実体を作れる型。
インターフェースとしいうのは、実体を作れない型。

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:45:23.62

「改変に強い」のは、インターフェイス自体の改変ではないよ。
改変に強い、って説明自体確かに誤解を招く表現で、
実際は「内部実装を気にしなくて良い」が正解だと思う。

インターフェイスとはちと違うけど、Streamなんかその最たるものじゃない。
Stream自体が何をソースにどうやって実現されているかは気にしなくてよくて、
処理する側はStreamクラスのオブジェクトに対して必要な処理（メッセージ）を要求すればいい。
インターフェイスを定義する、ってのはそれだけのことでしかない。

「Hoge(FileStream stream)」って定義したメソッドより、「Hoge(Stream stream)」って定義されたメソッドの方が、
汎用的に使えるじゃない。

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:54:34.76

改変に強いっていうのはどうなんだろうな
個人的には別に強くないと思うが

interfaceごしだと実装クラスを入れ替えられるけど
改変前と改変後の2つの似たようなクラスを両方保持して
interface越しにどっちを使ってるか分からなくするなんて考えただけでゾッとする
一つの具体クラスをただ書き換えるほうがずっといい

だから改変に強いと言うよりは
ライブラリを作る側が使う側に処理を実装してもらう時に使うものだと思うよ
IComparableを実装してもらってSortメソッドで使う比較関数に利用したり

まあC#3.0からラムダ式が使えるからそういう用途はもうほとんどお役御免だけどね
interface自体ほとんどお役御免といっていいと思う
ライブラリに残ってれば使うけど自作する意味は殆ど無い

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:57:08.75

ム板って取扱いと人種的に宗教戦争余裕なのに未だにIDないのか

**名無しさん＠お腹いっぱい。** · 2012/04/26(木) 23:57:13.32

インターフェースは、お役御免には、ならないと思うがな。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:04:32.27

interface I{ int Hoge(); string Hoge2(); }

こんなのを作るより

class C{ public Action Hoge; public Func<string> Hoge2; } こんなのを作って

new C{ Hoge = () =>{ ... }, Hoge2 = () => "hogehoge" }

こうしたほうが早いしわかりやすいし個別に設定できて汎用性も上だから
もうinterfaceを作る意味は無いはず

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:04:33.82

例えば、UnityやXNAやDxLibなどを同じように扱えるようにするにはどうするべき？
ゲーム本体部分とライブラリとの丁度境界線上にあるクラスはどのように定義すべき？

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:06:06.52

お役ご免ってのは言い過ぎでしょう。後々機能追加が考えられる場合、
その機能追加に耐える様Interfaceを定義するコトなんて、（自分は）ザラにありますよ。
たとえば、画像ファイルに対して順次いろんな処理をするようなソフトを作ったとき、
最初はjpgとbmpしか対応しないでおいて、いずれpngとかtiffもやりたいなあ、と思った場合、

interface ImageProcessor { ... }
class JpegImageProcessor { ... }
class BmpImageProcessor { ... }

なんて。
処理自体が短ければ>>18の言うとおり、ラムダ式で十分なんだけど、
色んな段階を踏む処理の場合、処理自体をクラス化しちゃう方が後々追加し易い。

>2つの似たようなクラスを両方保持して～一つの具体クラスをただ書き換えるほうがずっといい

っていうような懸念がある場合は、interfaceじゃなくて抽象クラスでやればいいし。
共通部分は抽象クラスで処理して、後々追加したい機能毎に変わりうる部分は具象クラスに任せて抽象メソッドを定義だけしておく、とか。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:10:18.02

>>23
もっともですねぇ

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:13:36.43

>>23
これだと違いはファイル読み込んでビットマップ作る
ビットマップをファイルに書き出す

ところが違うだけじゃないの

具体的なクラス一個作って

public Image(Pixel[][] bitmap)

こんなコンストラクタにして

new Image(JpegLoader.Load(file))
new Image(BmpLoader.Load(file))

書きだす時は

JpegWriter.Write(image.Pixels);
BmpWriter.Write(image.Pixels);

こんなもんでよくね

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:15:00.08

まあ、オブジェクト指向を完全に理解して常に完璧な形で実現出来てる、
なんて境地には到底達せないと思うので、今の自分の実装が正しいとも言い切れないんですけど。

Rxとか見てると、ラムダ式で全部・・・なんてのも決して非現実的ではないと感じるし、
「一つ一つの処理は短く」という基礎的なことを突き詰めていけば、
そういうこともきっとできるんだろうなあ、とは思う。

ただ、それでもinterface自体が無くなる可能性は低いだろうな。
俺は逆に、Rxが駆逐しようとしているのは開発者がclassを定義する、
という行為じゃないかと感じる。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:17:24.64

変数名につける英単語がわからなくて悩みまくる

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:17:43.59

>>25
それだと、あっちこっちで処理対象がJpegなのかBmpなのか判定しなきゃいけなくなるでしょう。
処理が読み込みと保存だけでいいなら、2箇所ぽっきりだしそれもありだと思いますけど。

Classとインターフェース作っちゃえば、インターフェースを介して処理してる本体側は大きな変更することなく、
一番アタマで対象の判定だけやって、クラスの実態をnewした後は同じ処理を続けるだけ、で行ける。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:35:15.50

極端に汎化するなら、こういうインターフェースを作るかな
interface ImageProcessor {
　　/// <summary>指定されたファイルがサポートされているかどうかを判定します。</summary>
　　bool Supported(string fileName);
　　/// <summary>指定されたファイルを読み込んで、オブジェクトを初期化します。</summary>
　　void Load(string fileName);
　　～
}
本体側は
AssemblyからImageProcessorを継承してるクラスを全部引っ張ってきておいて、
private static readonl List<T> processors;
private ImageProcessor processor=null;
private Load (string fileName){
　foreach (var p in processors){
　　if (p.Supported(fileName)){
　　　processor=p;
　　　break;
　　}
　}
　if (processor==null) throw new NotSupportedException(string.Format("{0}は未対応のファイル形式です", fileName));
　processor.Load(fileName);
}
みたいな。こうすれば、処理本体側は変更なしで対応形式の追加が出来るだろうし。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:35:54.03

まあ別にいいんだけどねこれでも

public Image(Func<Pixel[][]> reader, Action<Pixel[][]> writer)

public void Load()
{
　Pixels = reader();
}

public void Save()
{
　writer(Pixels);
}

これでinterfaceと大体同等だけど最初に入れてから入れ替えができなくて無意味に汎用性が下がるし
呼び出し側もメソッドの中で何が起こるのか分からなくなってソースがわかりにくくなるんで
必要がなければ避けるべき形だよね

public void Save(Action<Pixel[][]> writer)
{
　...　
}

処理の汎用化が必要でも、こんな風にライブラリ側だって必要なときに必要な物だけ渡してくれた方がわかりやすいし使う側も使いやすい
interfaceを使うと呼び出す場所(たとえばSaveを実際に呼び出すところ)とそれが定義されてる場所(Save処理を実装したクラス)が離れちゃうからわかりにくくなる
なにより「interfaceにそのメソッドが必要かどうか」という難しい判断をする必要がなくなるから問題がすごく簡単になる

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 00:40:53.37

まあ、やりたいことにあった方を選べば良いんじゃないかな。
実際、その二つの方法を提供しているライブラリも多いよ。
俺もそういうやり方することあるし。処理が端的に済む場合なんかは特に。

で、じゃあどっちかしか使わないか、っていうと、時と場合に依った。
どっちでも実現できる場合もあれば、どっちかじゃないとどうにもならん、とか
一方のやり方だとやたら遠回りなやり方になる、とか色々あったさ。

ライブラリを公開する、って観点で言うと、>>30みたいなやり方の方が使いやすいだろうな。多分。
実際、interfaceを定義する、っていう手間はあれで結構大変だし、ホントやりやすい方でやればいいと思うよ。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 01:33:59.48

ただ、制限がクリアできるならabstractの方が便利だけどね
interfaceで同一視したいクラスって、共通の処理がある程度有るし

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 01:37:13.24

（　・ω・）ｙ─┛～～

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 02:38:49.18

まあ実際、interfaceとabstract classどっちが多いかっつったら、
今まで書いてきたような目的下だと、abstract classの方が多いな。

**名無しさん＠お腹いっぱい。** · 2012/04/27(金) 10:42:30.93

>>22
ゲームで必要な機能だけを、ある程度そのゲームに特化した形で抽象メンバにする
間違っても汎用的なライブラリを作ろうなどと考えてはいけない

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 18:00:55.53

落ちた？

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 21:16:46.38

そんな早くdat落ちするのかこの板

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 22:23:13.82

しないね。サーセン誤爆だ。

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 22:24:15.68

基本プログラミングっていうのは自分でライブラリを書いて自分で使うことの繰り返しだからな
汎用性が高く使いやすいライブラリを書いていくと良いプログラムになる
使いにくく汎用性が低いライブラリを作るとソースがなんだかわからなくなったり仕様変更できなくなったりする

**名無しさん＠お腹いっぱい。** · 2012/04/28(土) 22:33:08.75

最初はそれも上手く行かなくて辛いけどな。試行錯誤を繰り返していく内に、
どうすれば汎用性が上がるかが分かってきて楽しい。

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 09:55:22.97

さんざ苦労してライブラリ作っても、意外と使わなかったりするな
使わずに温存してるうちに陳腐化したり、もっといいライブラリが登場したり…

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 13:38:00.37

今必要じゃないライブラリ作ってもしょうがないよな
テストもろくに出来ないだろうし

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:13:44.11

それあるよな。必要な物書いていったらいつのまにかライブラリになってたってのが理想的。

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:16:01.56

もはやライブラリを作るほうが本来の目的になってる時、あるよねw

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:20:20.22

作りたいツールを思いつく→ツールに必要なパーツを作る

→そこで満足する、または飽きる

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:24:44.61

そこが楽しさだからなぁ
完成が見えた時点でやる気が無くなる

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 19:45:24.02

デバッグが一番大変だわ
コード書いてる時は楽しいんだけど
バグを出すために色々やってみるとかキツい
自分が使うツールじゃなかったらまず無理

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:39:37.48

>>44-47
よう、おれ

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:42:49.73

前スレ埋まったw
ここに移動すんのか？

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:45:58.44

おかしい・・・みんなどこに行ったんだ

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:47:48.20

まあム板には相談室があるからふらっとがこっちにあっても
最悪質問者が誰もここまでこれなくて潰れても大して問題はないんだよな

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:47:52.52

じゃちっと立てれるか試してくるわ

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:51:38.15

あっ・・・ソフトウェア板様に、って貼られたテンプレをつかっちまった
スレタイ・・・すまない。

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 21:52:29.22

ふらっとVisual C#,C♯,C＃（初心者用） Part92
http://toro.2ch.net/test/read.cgi/tech/1335703825/

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:04:03.98

なんだかよくわからないことになってきたな・・・
どっちに来ても質問が来たら答えるだけだけど

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:09:46.37

VC#のデザインでコピーして貼り付けた時、Nameプロパティをコピー元に似せる方法ってないですか？
input_data_Box1ならinput_data_Box2とかinput_data_Box1(1)とかになってほしいです・・・

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:18:35.45

継承するかユーザーコントロールにしてInput_data_Boxっていうクラス名にしたらいいんじゃないの

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:27:06.67

ありがとうございます
特に付加する機能のない継承をやるくらいしかないんですね

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:29:44.31

多少手間だからユーザーコントロール作るか・・・！

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:32:06.71

俺はなにもかもユーザーコントロールにしてる
1クラスに配置するコントロールは4つぐらいまで
超えたらユーザーコントロールにまとめる

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:36:51.13

ユーザーコントロールって再利用性が全くないよね

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:41:21.18

>>61
んなことないでしょ
よく出てくる複数のコントロールの組もあるし(追加、削除ボタンの付いたリストとか)
WinFormは継承しなくても基本全部いじれるようになってるから
単一のコントロールでもDock.Fillしてユーザーコントロールのなかで機能追加したりも出来るし

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:48:34.11

>>62
俺は、コントロールのプロパティをバインドさせたりすることがよくあるから、
INotifyPropertyChangedインターフェースを実装したUserControlの派生クラスを作ってる。
他にも共通機能とかをまとめておけば、いちいち実装し直す必要ないし、便利。

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:53:51.89

>>61
まあ、変な基準でまとめると全く無くなる。
でもたとえば、ファイルパスを入力するテキストボックスと、参照ボタンのセットとか、
意外とよく使う組み合わせ、ってのは多いからな。

>>60のいう4つくらいまで、っていうのは何だか凄いな、と思うけど。
レイアウト系のパネル配置し出すと、4つなんて容易に越えてしまいそうなもんだが・・・

**名無しさん＠お腹いっぱい。** · 2012/04/29(日) 22:54:42.98

×パネル
○コンテナ

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 00:30:14.37

荒らしの人は相談室に行ったみたいだな

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 01:20:42.98

全部作り終わってから、ちまちまとライブラリに落としこんで行ったら動かなくなった。元に戻しても動かない(´・ω・｀)

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 01:32:15.13

>>66
素人考えの眩暈のするような間違った内容だけど、自分の考えを書いてはいるんで別の人かな。
JITの話が出てたんで関連Tips

・JITとインタプリタは違う
・JIT結果はAppDomainをまたいで共有される
・Assemblyにする段階で構文解析終わって中間コードになってるためJITは高速
・コールドスタートアップだとJITコンパイラの読み込みに時間がかかる
・全部NGENしとけばJITコンパイラの読み込み自体がスキップされる
・JITさせたくないならNGENしときましょう

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 05:39:30.54

>>67
動かなくなるようなライブラリの落とし込み方ってどうやるんだ・・・
クラス単位で名前空間移して別DLLにするだけだろ？
アプリ側で随時using追加すれば動かなくなることなんてないだろ・・・

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 08:12:58.08

いまさらだがテンプレ抜けていたので

■備考
コードの量が多い場合は下記サイトを使うなどしたほうがいいかも
http://ideone.com/
http://pastebin.com/
コードを貼り付けてrun codeのチェックをはずしてsubmitボタンを押すと
コードを鯖側にアップして専用のアドレスが発行されます

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:47:11.06

複数のテキストボックスを入れたコントロールを用意し、
テキストボックスのTextプロパティ等をコントロールのプロパティで変更できるようソースに追記しました
（デザイナーで初期値を変更すること、プログラム上で参照することが目的）
デザイナーで初期値を変更することはできたのですが、プログラム上で参照することができません

using ディレクティブまたはアセンブリ参照が不足しています。
とエラーが出ます

検索するとNamespaceを追記すると良いと出てくるのですが、コントロールと本体のNamespaceは同じで、
最初から付いているコントロールのTagプロパティは参照できます
Modifierをprivateからpublicに変えたりもしたのですが、駄目でした

ソースは次レスで書きます

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:48:09.55

//○プロパティの追加（1例）
public string Text_Box_Tag
{
set
{
input_tag_Box.Text = value;
}
get
{
return input_tag_Box.Text;
}
}

//○本体
//Tagの代入
foreach (Control item in Text_input_group.Controls)//コントロールはText_input_group内に配置しています
{
if (item.GetType().Equals(typeof(Control)))
{
int a=(int)item.Tag;//元からコントロールにあるTagプロパティは取得できます　中身は0～です
Tag[a]=item.Text_Box_Tag;//追加したプロパティ　エラー
Key1[a]=item.Text_Box_Key1;//追加したプロパティ　エラー
Key2[a] = item.Text_Box_Key2;//追加したプロパティ　エラー
Data[a] = item.Text_Box_Data;//追加したプロパティ　エラー
}
}

処理が足りていないのでしょうか？
へ、ヘルプ・ミー

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:51:06.91

一例、でわかるかよ。
そのプロパティの中に原因があるんだろ。

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:51:59.35

ン？違うな。なんだこのソース。
そもそもコンパイルできねえじゃん。

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:52:49.07

プロパティを追加したとかいうクラスの名前はなんだかしらないが、
そのクラスでキャストしなきゃそのプロパティにアクセスできるわけないだろう。

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:52:54.05

複数のテキストボックスを入れたコントロールのクラス名をTextBoxesControlとすると

if (item.GetType().Equals(typeof(TextBoxesControl)))
{
//ちゃんとTextBoxesControlにキャストする
TextBoxesControl boxes = (TextBoxesControl)item;

int a=(int)boxes.Tag;//元からコントロールにあるTagプロパティは取得できます　中身は0～です
Tag[a]=boxes.Text_Box_Tag;
Key1[a]=boxes.Text_Box_Key1;
}

みたいなかんじでキャストすると、追加したプロパティにアクセスできるよ
Controlのままでは追加したプロパティにはアクセス出来ない

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:53:49.60

エラー、ってコンパイルエラーのことだったのね。浅はかな回答して済まん。

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 16:57:55.31

>>76
なるほど
クラス名でキャストしてあげる必要があるんですね
無事コンパイルが通りました
ありがとうございました

>>77
いえ、私の説明不足ですみません

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 18:03:22.34

本スレはいよいよ崩壊しているな・・・
回答がままならない

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 18:05:04.00

初心者の質問に初心者が答える正に初心者用スレッド

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 18:06:33.19

あの状態で答えられるエスパーは確かにあのスレにはおらんな。
たまにエスパーのいるスレがあるけど、ああいうエスパー達はどういう次元にいるのか理解が及ばない。

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 18:06:38.03

あれはIDの必要性を分からせるための自作自演に違いない

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 18:10:32.67

ふと思えば、そもそも、あのプログラムでxcopyを使う必要はあったんだろうか・・・

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 18:42:57.19

>>77
コンパイルエラーと言えば、今作っている奴がコンパイル完と共にVSがエラーで落ちるorz
その後再起動すると普通に動くんだが、修正するとコンパイル後に落ちる
どっかのシンボル名が問題起こしているっぽいのだが情報有ったら教えて貰えませんかね？

**名無しさん＠お腹いっぱい。** · 2012/04/30(月) 18:43:59.26

マイクロソフトのサポートに電話すれば

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 09:16:04.91

TextRenderer.MeasureText のオーバーロードの一つ

public static Size MeasureText(
　IDeviceContext dc,
　string text,
　Font font,
　Size proposedSize,
　TextFormatFlags flags )

proposedSizeの意味がさっぱりわからないんですが
誰かバカな私に噛み砕いて教えて下さいませんか？
ちなみにバストは86cmです

MSDNにはこうありますが……
When measuring text on a single line, if the proposedSize parameter represents a Size with a height dimension greater than Int32.MaxValue , the returned Size will be adjusted to reflect the actual height of the text.
1 行のテキストを計測したときに proposedSize パラメータが Int32.MaxValue より大きい高さを持つ Size を表している場合、返される Size が調整されて、実際のテキストの高さが反映されます。

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 09:18:00.24

>proposedSize パラメータが Int32.MaxValue より大きい高さを持つ Size を表している場合

ここんところが意味不で困ってます
Size.HeightはintですからInt32.MaxValueより大きいってどゆこと？

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 11:14:15.23

MaxValueより大きい・・・・ジャスコだな

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 11:18:40.05

MaxValueって31bit+符号で表現できる最大ってことじゃなかったっけ？
ファイル長なんかだとLongも一緒につかえるよね

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 11:48:39.69

見た感じproposedSizeに収まるテキストの最大のサイズを返すんじゃないか
MSDNがバグってるんだろう

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 13:43:26.40

DataGridViewのFillの挙動が気にくわない。
「表示幅が余ったときはFill、それ以外の時はAllCells(ExceptHeader)」みたいな挙動をさせたい場合、
DataGridViewの継承クラスで容易に実装できないもんかな・・・
FillWeightとの絡みとか考えたら大変そうっちゃ大変そうなんだけど、
元々のFillの挙動（表示幅が不足すると、見切れてしまうしサイズの変更も出来ないしで詰む）が頭悪すぎて
どうにもこうにも。

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 13:47:06.71

protected virtual CalculateColumnSizeCode とかそういうメソッドが隠れてねえかなあ、と
探したけど、それっぽいの無いんだよね・・・。

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 13:47:57.54

×Code
○Core

**名無しさん＠お腹いっぱい。** · 2012/05/01(火) 20:46:32.83

知らんけど一個一個MeasureTextして入るかどうか調べればいいんじゃねえの？

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 00:13:17.88

相談室荒れてるな
韓国コピペも相談室言ったか

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 01:26:06.18

失礼します。改行コードについての質問です。

改行1つをRead()で読み込むと10進で1310が返ってくるのですが、
これはCR(10進で13)とLF(10進で10)をまとめて1文字として読んでいるという認識でいいのでしょうか。
だとすると、CR+LFと\u051E（16進51Eは10進で1310）とはどう区別して判定するのでしょうか。
（\u051Eなんてめったに使うものではないでしょうが。）

もうひとつ、int型の1310をString.Format(string, Object)で16進変換すると"DA"が返ってます。
1310を分割して13->"D",10->"A"としているのだと思いますが、
これはどういうロジックでこうなるのでしょうか。なぜ"51E"ではないのでしょうか。

よろしくお願いします。

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 01:39:43.60

CRが13,LFが10の2文字でしょ
2文字をいっぺんに読んで、何かよくわからない過程を経て1310に到達してるんだろうと思うけど

http://ideone.com/FlooQ

1310は16進数だと51Eになるみたいだよ

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 03:00:20.14

自己解決しました。一度のつもりの処理を二度行っていただけでした。

こんなことで小一時間悩んでいたなんて・・・

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 05:46:56.72

文字コードの制御コードはすべてアスキーコード互換じゃないかな？
http://e-words.jp/p/r-ascii.html

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 05:48:39.32

おIDがあるｗ
ソフトウェア板に移動したのかｗ

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 05:50:21.13

で、windowsがなんで2文字のアスキーコードが返ってくるかといえば
http://ja.wikipedia.org/wiki/%E6%94%B9%E8%A1%8C%E3%82%B3%E3%83%BC%E3%83%89

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 13:23:51.82

やっぱIDいいよな
ない向こうは相変わらず荒れてるし
必死にIDあり移住に反対してた奴はいなくなったようで平和だ

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 14:33:24.10

でも向こうのほうが盛り上がってるし・・・

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 17:04:16.32

ここは盛り上がることが目的と違うし。
避難所、って銘打ってるんだからそれでいんじゃないの。

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 19:22:47.29

休みで暇なやつが荒らしまくりだな
あっち

**名無しさん＠お腹いっぱい。** · 2012/05/02(水) 19:35:09.34

まあ程度が知れてる。完全に荒らし目的だろうから、どうでもいい。

**名無しさん＠お腹いっぱい。** · 2012/05/03(木) 01:24:57.53

C#で作られてるソフトで、無償で、おまけにソースも見られる
そんな勉強するのに便利なフリーソフトってありますか？
他人のコードを見て勉強したいが、日曜ｸﾞﾗﾏにそんな友達は居ない。