ふらっと C#,C♯,C＃（初心者用） Part137
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■関連スレ
C#, C♯, C＃相談室 Part95
http://mevius.5ch.net/test/read.cgi/tech/1508180530/
C#, C♯, C＃相談室 Part93
https://mevius.5ch.net/test/read.cgi/tech/1492818720/
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part136
http://mevius.5ch.net/test/read.cgi/tech/1520057345/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/ja-jp/library/gg145045.aspx
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>146
ちがくね？
お前がやりたいのって別のデータとid（？）が一致する項目にデータを入れていきたいんじゃねーの？
でもそれってコントロールを特定する必要があるんだよね？
コントロールとデータを紐付ける何かはあるの？ GetAllControlsのカウント取るとかそういう？ VB6はコントロール配列があったけどなー。.Netの世界にはないからの。 ttps://dobon.net/vb/dotnet/control/findcontrolbyname.html
名前で探せばいいのでは？ だから配列に突っ込めば済む話を何でわざわざより面倒な方法で解決しようとするのw >>149
いや、単純にファイルから読み込んだ名前で、チェックボックスの文字を変えたいだけです
例えばファイルの中身が 犬,猿,雉だったら？CheckBox1-3の文字をそれぞれ犬、猿、雉にしてCheckBox4-20は「使用不可」にでもするような
だから機械的に参照できればよかったのです
>>153
これでほぼ解決です、ありがとうございます >>154
まあ一言でいうと、わざわざ自分で配列を作らなくても、それを実現する方法はすでに存在するだろうと思ってたのです
配列作ったら「そんなことしなくてもこう書けば一発で参照できるのに」って言われる方法があるんじゃないかと >>155
その下にインデクサによる説明もあるだろw public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
this.checkBoxes = this.Controls.OfType< CheckBox >().OrderBy( x => x.Name ).ToArray();
}
private CheckBox[] checkBoxes;
} public class B : private A
{
}
みたいなこと C# じゃ出来ないんだっけ？ >>159
継承元をprotectedにすれば継承したクラスからしかアクセスできないようにはできる そのクラス経由でしかアクセスできないようにしたいってことじゃないの？ ゆとりしか居ないのかなぁ
C#はprivate継承はサポートしてないよ
フィールドに持たせて移譲メソッド書くしかない >>163
ゆとりなんてもうオッサンやでおじいちゃん？ これ参考にすればいいのかな
http://ufcpp.net/study/csharp/oo_conceal.html
protected internal 同一プロジェクト内のクラス内部、または、派生クラスの内部からのみアクセス可能
private protected (C# 7.2 以降)同一プロジェクト内のクラス内部、かつ、派生クラスの内部からのみアクセス可能
こういうこと？ >>155
それで解決しねーだろ
バラっバラにくんじゃね？
俺はてっきりコントロールの
座標でソートして名前付けたいのかと思った 皆様いろいろありがとうございました
>>158
書いてくださった方法が、ほぼ私が求めていたものを完璧に実現しています
抱かれてもいいくらい惚れました
ただ、試してみたところピックアップされる順番は必ずしもコントロールを配置した
順番通りではなく、はっきりした法則性も見いだせませんでした
テストプログラムを書いて、インデックスと見た目を一致させるようデザイナで
コントロールを並べ替えようかとも思いましたが、後日コントロールを追加した際
悩むことになりそうなのでやめておきました
>>153
結局この方法でコントロールを検索し、発見したコントロールをリストに追加するという
方法で対応することにしました
>>154
配列に突っ込むにも、コード上に直接 checkBox1 とか checkBox2 とかのリテラルを
埋め込みたくなかったので、検索した上で配列を作ることにしました
>>148, 150, 151
実は書いていることがわからないレベルなので、これから勉強します
「作って覚える」は一通りやったので、「独習c#」を紐解いてみます
>>166
これで解決しました
158の方法で解決するかと思っていたのですが、やってみたところバラバラの順番でした
皮肉でもなんでもなく、コントロールの座標でソートとか、なぜそういう操作をしたいのだろうと
推測したのか教えていただけると嬉しいです
今後も質問すると思いますので、疑問点がわかりやすい文章を意識する必要があるので 今日からC#勉強し始めたけど、
結構ネスト深くなる言語っぽいね、これ。こんな…
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
try
{
checked
{
sbyte a = 64;
sbyte b = 65;
sbyte c = (sbyte)(a + b);
}
}
catch (OverflowException ex)
{
Console.Write(ex.Message);
}
}
}
} >>167
いやいやいやcheckBox1 とか checkBox2 とかはリテラルじゃないってw
ただの識別子（フィールド名）
コードにリテラルを埋め込むというか、コンパイル時に誤りを検出できない
（普通の理解では）お行儀の悪いコードになるのはむしろ>>153みたいな方法だってw namespaceとかcheckedがブロックなのが何かなぁ… >>169
おっと・・・
どうやら根本的なところで間違っていたようです
書いてあるとおりだとすると、質問とレスが噛み合っていない理由がわかりました
わざわざ行儀の悪い書き方を探していたのか >>167
>>158はOrderBy()でチェックボックスの名前(Name)順にソートしてる。
Nameの代わりに、TabIndexかTagを設定してそれを利用しても良い。
というか、Nameだとチェックボックスが10個以上になるとソートが望むようにならないか。 >>167
おそらく配置したコントロールから欲しい情報は座標とサイズぐらいしかない
それらの特定情報は別ファイルにある
なのでコントロールが上から
もしくは左からか順番に取得できれば
別ファイルに記述した通りの順番で情報を並べることができる
Controlsで取得できる順番はよく知らないけど
作った順かあるいわなんの特徴もなくランダムか何かを保証するものではないのかな？と >>173
Controlsが返す順番は保証されてないけど、自分でソートすれば良い。
(1)TabIndex順 (各CheckBoxにタブオーダー(TabIndex)を設定しておく)
this.checkBoxes = this.Controls.OfType< CheckBox >().OrderBy( x => x.TabIndex ).ToArray();
(2)Tag順 (各CheckBoxのTagに数値を設定しておく)
this.checkBoxes = this.Controls.OfType< CheckBox >().OrderBy( x => x.Tag ).ToArray();
(3-1)Location順(左から)
this.checkBoxes = this.Controls.OfType< CheckBox >().OrderBy( x => x.Location.X ).ThenBy( x=> x.Location.Y ).ToArray();
(3-2)Location順(上から)
this.checkBoxes = this.Controls.OfType< CheckBox >().OrderBy( x => x.Location.Y ).ThenBy( x=> x.Location.X ).ToArray(); >>155
そういう使い方なら、チェックボックスを先に作っておくんじゃなくて
ファイルから読んだ内容で動的に作っていった方が手っ取り早い
どうせチェックボックスは全部等間隔に並べるんじゃろ？ >>126,>>128
>>123です
SetPrinter関数を使用することで実現できました。ありがとうございました。 >>178
ネストのイメージ書きたかっただけだろうよ >>173
なるほど、コントロールから情報を取得する必要があると思えたのですね
実際はそれ以前の段階でしたが
>>175
それも考えたのですが、デザイナで画面を確認したいので、静的に用意して
おきたいという結論になりました
動的に置くほうが難易度高そうだ、と思ったのもありますが >>178-179
「意味無い」って、どういう意味？ うーん、string x = "10"; に対して
x.toString(); するんじゃなくて、int.Parse(x); するのか…。
xオブジェクトにintegerを吐き出させるのではなく、
integerオブジェクトにxオブジェクトを与えてintegerを吐き出させる…。
これは初めての体験だな…。 expression-bodied関数は、なんかエロいな… やってる事は違うけど、考え方的にはCのマクロに近いのかな… なんだよ、ToString()メソッドあるじゃねぇかよ…。 >>190
ごめん。
質問です。なんだよ、ToString()メソッドあるじゃねぇかよ… VisualStudioでC#のフォームアプリを開発するときに
プロジェクトのプロパティから
出力の種類を「コンソールアプリ」にして
デバッグ用のConsole.WriteLineを出力できるようにしてるんだけど
リリースするときは、種類を「Windowsアプリ」にするだけで
コード中のConsole.WriteLineはコメントアウトとかしなくても
大丈夫ですか？ >>193
デバッグ用に文字列を出したいなら、using System.Diagnostics;して、Debug.WriteLine()とか使うべき。
これならリリースビルドにするだけで無効になるからコメントアウトも不要。
リリースビルドでも使いたいなら、Trace.WriteLine()。 >>194
おお、ちゃんとデバッグ用のがあるんだ
聞いてよかった
ありがとう
>>195
なるほど
別に見られて困るようなものでも無かったけど
無知を晒す所だった・・・
てか、独学でやってると気づかずおかしなことやってそうで怖いわ
たまたま、ネット上で解説見つかるか
質問して教えてもらえるかの
綱渡りで進んでるｗ >>192
おまえ出身言語化どこだよw
レヴェルが低すぎるぞ 引数の文字列が、データグリッドに含まれていない場合だけ追加したいんですが、追加されません。
何が原因でしょうか？
void AddToDataGrid(string[] strs)
{
bool exists = false;
foreach(string str in strs)
{
for(int i = 0; i <= view.Rows.Count; i++)
{
if(str == view[0, i].Value.ToString())
exists = true;
}
if(!exists)
{
view.Rows.Add(str);
}
}
} >>198
>view.Rows.Add(str);
これじゃね >>199
view.Rows.Add(str);
だけだと正常に追加されるので、条件判定かループあたりに原因があると思っています。
フラグの位置がおかしいので以下に修正してもダメでした。
void AddToDataGrid(string[] strs)
{
foreach(string str in strs)
{
bool exists = false;
for(int i = 0; i <= view.Rows.Count; i++)
{
if(str == view[0, i].Value.ToString())
exists = true;
}
if(!exists)
{
view.Rows.Add(str);
}
}
} >>200
exist=trueでブレークポイントを置いてデバッグ実行すればわかるのでは？ そもそも exists = true; の行に到達してないというオチな気がする >>201とかぶってしまった
>>201の方が指摘として親切だからそっちだけ読めばいいよ >>200
for(int i = 0; i < view.Rows.Count; i++)//Rows.Count以下じゃなく未満
{
bool exists = false;//ここに移動
if(str == Convert.ToString(view[0, i].Value))//ToString()だとValueがnullのときエラー >>204はとってもそれっぽい
で、例外が握りつぶされるような場所でAddToDataGridが使われてるせいで気づけてないとか
こういう場合自分はtry{...}catch(Exception exception){throw;}で囲って
throwの直前にブレークポイントを置いたりしてるけどもっとうまい方法があったら誰か教えてちょ >>204はそれっぽいと言ったけど
よく読むと
bool exists = false;//ここに移動
の部分は自分には理解できなかった
>>204の勘違い？ >>206
フラグよく見ていないからとりあえず
if(str == Convert.ToString(view[0, i].Value))
{exists = true;break}
に変更で みなさん本当にありがとうございます。
結局原因はわからず仕舞いでしたが、最終的に以下の方法で打開しました。
void AddToDataGrid(string[] strs)
{
foreach(string str in strs)
{
bool exists = false;
for(int i = 0; i < view.Rows.Count; i++)
{
if(Convert.ToString(view[0,i].Value) == str)
exists = true;
}
if(!exists)
{
view.Rows.Add(name);
}
}
} >>208
それなら納得
existsの宣言の位置を移動するとif(!exists)がスコープから外れちゃうもんね
>>209
>>204の方法で解決したんなら>>204の指摘が正しかったんでしょうよ
で、それに気づかなかったんならやっぱり例外が握りつぶされてたんでしょ
なら今後のためにも原因は分からずで片付けず例外の名前くらい確認しといたほうが良いと思うよ オブジェクト指向のプログラミングでは
変数じゃなくてプロパティにアクセスさせるべき
みたいな事をよく聞くんだけど
・プログラムの開始時にあるフラグ(true/false)を決めて、その後一切変更されることがない
・そのフラグには、コード中の様々な所からアクセスがある
って場合は、プロパティじゃなくてpublicな変数でフラグを定義してもいいんですか？
オブジェクト指向がよくわかってないせいか
プロパティを経由するのがどうしても遠回りというか
一つ余分な作業を挟んでるように感じてしまう・・・ 変数は、公開しちゃダメ
その変数に、誰かが代入するかも知れないと考えると、
その変数に代入しているか、すべての場所を確かめないといけなくなるから、
プログラミングできなくなる
だから、プロパティで代入禁止に設定する
ただし、絶対に代入できない定数なら、公開してもよい >>212
後から書き換えられるのを確実に防止するために
プロパティを使うってことか なるほど
1人でコード書いてるからそういう発想が無かったけど
自分も後から絶対変な値を代入しない保証ないもんな
てことは、>>211の例だと
・引数付きのコンストラクタを使って、フラグの状態をインスタンス化
・そのフラグのプロパティはgetのみ設定
ってすればいいのか？
でもこれだと、そういうフラグを立てるタイミングがたくさんあったら
その分だけクラスを準備しとくことになると思うんだけど
そういうもんなの？ あ、いや
クラスを複数準備する必要はないな
>>213の後半の話は無しで >>211
212は読まなくていい
フィールドだってreadonly修飾子で代入禁止できるが、212はそんなことも分かってないから
プロパティがフィールドと違う点は大ざっぱに
* 派生クラスでオーバーライドできる
* プロパティから構造体を返すとコピーされる
の2点
この2つの特性が必要ない(または避けたい)場合にフィールドを選択してよい
判断できないならプロパティを選択する >>215
>* プロパティから構造体を返すとコピーされる
これが、全然分からんのだけど
classの代わりにstructを使った場合の話であってる？
今の自分が考えたところで、どうせちゃんと理解出来ない気もするけど >>212は別に全く問題ないだろ。
>>211の要はカプセル化の質問に対して、>>212はカプセル化の話として一般論として答えただけじゃん。
それに対して>>215と>>217はここはC#のスレだからC#特有のreadonlyなフィールドあるよとか言語依存の情報
つけ足してるだけじゃん。 オブジェクト指向では、変数は公開しない。
公開できるのは、処理(関数)だけ
クラス内を開発する人と、そのクラスを使う人は、別の会社・人を想定しているから、
変数にアクセスさせたら、絶対にダメ
クラス内を作っている開発者は、後で付け加えられる処理を予想できないから。
クラス内を開発した後に、別人が変数にアクセスして、動きを変えたらバグる
異なる会社間での開発を可能にする、
オブジェクト指向の大原則・カプセル化 プロパティから構造体を返すとコピーってのは意味わかんないね
コピーされるのは右辺がプロパティだろうがフィルドだろうが同じだよw
>>211
少なくともパブリックなメンバーに関しては、あえてフィールドを使う理由はないって
理解でいいと思うよ。例外はアンマネージドコードの呼び出しで使う型を定義する場合ぐらい。
フォールドのプロパティーに対して優位な点は
(1) 軽量である
(2) 簡潔に書ける
このぐらいしかない。
(1)が重要なケースなんかまずない。
(2)については、古いC#はともかく今のC#は儒分簡潔に書けるようになって来てる。 >>220
カプセル化っていのは、触る必要がないもの、触られては困るものを隠すこと。
この質問にはほとんど関係ない話w
フィールドをプロパティにしようが、触る必要がない文脈で触られることを防げるわけじゃないw
せいぜいセッターで値が適切かどうかチェックできる程度 まぁ、むしろ>>211のカプセル化などの話に対して、考え方説明せずに
初心者にいきなり言語仕様の詳細を羅列する>>215の方が教え方としてははぁーー??だわww >>222
質問者は
>オブジェクト指向のプログラミングでは
>変数じゃなくてプロパティにアクセスさせるべき
>みたいな事をよく聞くんだけど
で書いて始めてんじゃん。だから、カプセル化の説明した方がまずいいんじゃねぇか？？ >>224
何が「だから」なのかよくわかりませんw
質問は外部に見せるデータをプロパティとして実装すべきかフィールドでもよいのか。
カプセル化（余分なものを外に見せるな）は何も関係ないってw >>224
>オブジェクト指向のプログラミングでは
>変数じゃなくてプロパティにアクセスさせるべき
>みたいな事をよく聞くんだけど
を質問者が引き合いに出した以上、質問者はここからはしっかりわかってなくて、色々ごちゃ混ぜになってると
思われる。だから、そっから説明しなきゃ、おそらく習得できない。 自分はオブジェクト指向じゃない言語をちょっとだけやってたんだけど
そういう言語では、コードの最初の方に
public bool JudgFlag = true
って1行書いて、それにどこからでもアクセスするみたいな感じだと思うんだ
（全部独学だからこれも正解なのか知らんけど）
でも、オブジェクト指向ではこれやったらダメなんだよね？
ってのが知りたい
後、俺マジで初心者だから
質問文で聞きたいことが正確に表現できてる保証ないｗすまん >>227
別にダメじゃないよw
何度も言うけど、あえてフィールドを使う理由があんまりないだけw
フィールドをプロパティにしたらバグが減らせるとか可読性が上がるとか、
ほとんどの場合そんなことはない >変数じゃなくてプロパティにアクセスさせるべき
これが異なる会社間での開発を可能にする、
オブジェクト指向の大原則・カプセル化
どの教科書にも書いてある
その理由は、クラス内を開発している会社・人と、
そのクラスを使う会社・人は、異なっているから
オブジェクト指向では、これらの2つの立場からの見方が大切。
君はどちらの開発者ですか？
クラスを作る方・使う方？
クラス内を開発しているのは、過去だから、
そこから未来の、クラスを使う人の動きを予測できない
だから、変数に直接触らせたらダメ。
そこまで予測して、クラス内を作れないから >>229
そうなのか・・・
でも、解説サイト見てると
「ダメ」的な雰囲気で書いてあるとこばっかりじゃない？
俺の理解が間違ってるのかもしれないが
俺的には現状>>229に書いてある事が正解に思えちゃうんだよな
俺が1人で小規模な開発してるだけだから
いまいちオブジェクト指向のメリットを感じる場面が少ないのかな >>227
>public bool JudgFlag = true
変数を公開したら、ダメ。
カプセル化にならない
理由は、
>>212
に書いてある >俺が1人で小規模な開発してるだけだから
>いまいちオブジェクト指向のメリットを感じる場面が少ないのかな
まあこれだな
>>212の言ってる事は、OOPの「思想」としては間違いなく正しい
但し、単独での小規模開発という状況を前提にするなら「現実的なメリット」は無いに等しい >>227
うん。君のケースだとダメだね。それだと、クラスの内部状態JudgFlagが誰でも自由に書き換えられちゃう。
だから、まずは君は基本、>>220のようなC#とか言語関係ない一般的なカプセル化について勉強しよう。
で、君のケースだと自分で書いてるが
>・引数付きのコンストラクタを使って、フラグの状態をインスタンス化
>・そのフラグのプロパティはgetのみ設定
ってやるか、
getプロパティ書くの嫌なら>>215が書いたようにC#にはreadonlyフィールドというのがあるのでそれで代用できる。 おまえら変数は公開しちゃだめだけど、プロパティやgetter/setterなら公開してもいいって思っとるやろw >>231
どこの世界でも教条的（思い込みが激しいともいう）人はいるからねw
外部から取得/設定してもらう必要がある値をフィールドではなくプロパティにしたからって
ヒューマンエラーを減らす効果なんかないのは事実
ただ機能がより少ないフィールドをあえて使うことないでしょってだけの話
オブジェクトの公開するデータは必ずしもいつも変数に入っているわけではなく、
何らかの処理の結果を返す場合もあって、その場合はプロパティになるから、
だったら全部プロパティの方が統一感があるという考え方はあるかもしれない まとめると
「1人で小規模なコード書いてるだけなら
public bool JudgFlag = true
を書き換えたらダメなことぐらい自明だから、フィールドに1行書いて終わりでいい
若干雑だけど楽」
って考え方と
「いや、自分で決めたルールを自分で忘れることもあるから
ちゃんとプロパティにして触れない様にすべき
多少面倒でもコストを払うメリットがある」
って考えの対立なのかな
get;set;とか全く意味がわからなかった頃の嫌なイメージのせいで
プロパティを書く事が、「面倒・難しい」って体が拒否反応しちゃうんだよね
自動プロパティとか実装されてる今の時代に
何言ってんだって笑われそうだけど
まあ、でも色々モヤモヤしてた所がスッキリしました
ありがとう フォーム間のデータ受け渡しのやり方について教えてください
プログラムを起動して、最初にForm1でパラメータなどを設定、次にForm2で設定した
パラメータを元にデータを編集したいとします
（Form1で編集済みのデータをForm2に表示する、でもいいです）
このときにデータを受け渡すのは、program.cs で Application.Run(new Form1()); と
呼び出す前に
1. Form2 のインスタンスを作っておいて、それを Form1 の引数として与えてやる
2. 必要なデータのインスタンスを Main() 内に用意しておいて、そのインスタンスを
Form1 と Form2 のそれぞれに送る
3. どっちもダメで他の方法がある
のどれが良いのでしょうか。
Form1 の中で Form2 のインスタンスを作成して、Form2 に送るという方法も考えましたが、
そうすると Form1 が不要になったときに Dispose() すると Form2 も落ちてしまいます。 >>240
それは右座標を計算して返しただけであって処理を実行するのとは違う
面倒だからここ読んで
https://msdn.microsoft.com/ja-jp/library/ms229054(v=vs.100).aspx >>241
Form2にプロパティを追加
Form1の該当メソッド内でForm2を宣言＆インスタンス化してプロパティにパラメータをセット
Show(Dialog)メソッドで呼び出し メッセージキューを勉強中なんですが、
MSMQとMessageQueueクラスって何が違うんでしょうか？ >>244
ありがとうございます
この場合、もう二度と Form1 を使わないという状況であれば、Form2 の ShowDialog を
呼び出す前に this.Hide(); で隠しておいて、戻ってきたら this.Dispose(); でしょうか
Hide() だけで処理を抜けるコードを書き忘れて、いつまでもプログラムが残り続けるバグを
やったので、二度と戻ってこないフォームは Dispose() したいのです ■ このスレッドは過去ログ倉庫に格納されています
