ふらっと C#,C♯,C＃（初心者用） Part147
■ このスレッドは過去ログ倉庫に格納されています
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part146
https://mevius.5ch.net/test/read.cgi/tech/1576069931/
■関連スレ
C#, C♯, C＃相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/index
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET .NET Tips
https://dobon.net/vb/dotnet/index.html
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >>772
STAスレッド(Formのスレッド？)で処理していたらUIの更新が行えないので
正しい動作かな
ClipboardクラスはSTAでしか動かないってなっているので、asyncメソッドでtaskを
実行してdelegate経由のinvokeで呼び出すんじゃないかな SIer業界がブラックな理由を解説する。エンジニアは自社開発をしているWeb業界がオススメ！
https://www.youtube.com/watch?v=iy4nnAI9og4
エンジニアの仕事が稼げる理由とは？プログラミングスキルと
仕事の需要は比例しないので、実は技術力が低くても稼ぐことができる！
https://www.youtube.com/watch?v=82Bs-NH8jAM
通勤時間が長い人ほど無能説。家賃節約とか言っている暇があったら、
会社の近くに引っ越して浮いた時間に副業したほうがお金も貯まるし強くなれる。
https://www.youtube.com/watch?v=mt6K1RJnk6I
プログラミングに英語は必要か？に対する明確な答え
https://www.youtube.com/watch?v=WWULJbVECKU
私がヤフーを辞めた理由
https://www.youtube.com/watch?v=-G-7Hc3rJw8
【業界研究】IT業界でひと括りにするのは危険。SIer、Web制作、
アプリ開発で仕事内容が全く違います。【就活・転職】
https://www.youtube.com/watch?v=_IJQ2iBkf4w vb.netとc#の大きな違いってなんでしょうか
仕事で後者を触らないといけないんですが そんなに大きく違いますか？
文法書見てる感じではそこまで大きな差はないなかな、と思ったりしてますが >>782
どっちも.NETベースだから基本は大して変わらんけどC#のほうが長続きしてるのでVB.NETにない新しい言語機能がいろいろある >>782
あんまり意味のある質問に思えないんだけどw >>782
言語仕様はほぼ一緒なんだけど使い手のレベルとか文化とかに雲泥の差が
控えめに言ってVBしかできないような人は20世紀から取り残されたゴミみたいな開発者が大半
BASICの歴史的な経緯からくる負の遺産、いままでに蓄積されたクソコードもてんこ盛り
VBに関わるとダメプログラマに転落するぞ
といいつつC#でも下手するとVS2005〜2008位で時間が止まったままの案件も結構あるけどな
そういう現場にどっぷり漬かるとVBでもC#でもダメエンジニアへの道まっしぐらだ っていうか言語で出来ることが変わるとか制限あるのがおかしい
日本語の「ツンデレ」を訳せる言語が無いとかそういうレベルと違う VBはちょっと。。
言語もだけど、書く人の頭が古いからコードまで至るところで古さを感じる
多重for、ifとかそんなレベルで
VB現役でやってる人でもすごい人はいるんだろうけど、稀有やろなあ VBの言語仕様はラムダ式とかクロージャと相性が悪い C# と VB.NET、同じコード書いても IL レベルで見るとVB.NET側にゴミが付くんだよな C#とVB.NETどっちも選べる状態でVB.NET選んでる人やプロジェクトってどれくらいあるんかな？ 数年前に作られたVB.NETのWebシステム知ってる
オフショアで作らせたら動く粗大ゴミが誕生したと聞いた
詳しくは知らんが 自分が作ってるツールはexcel操作する場合
いつもvb.netで書いてしまうわ VBはC#より稀に先進的な記述方法がある
行末に;要らないとか
つかC#もそうして欲しい
簡単だろ C#で書いてると、たまにVB使うとエンターキーの違いでイラっとくるわ VBに限っては改修業務が良い
新規でVBとか考えたくない public Class MyCustomForm : Form
という自作の拡張Formクラスを作り、コンストラクタで色やいくつかのコントロールを配置したものをメインのForm1で継承させ、コンパイルも上手くいき実際の動作も希望通りではあるのですが、
上記のMyCustomFormのコンストラクタ内で追加したコントロールがデザイナで編集することができません。
まるで背景画像かのように選択すら出来ないものや、選択こそ出来てもAutoSizeやLocationなどの項目が灰色掛かって編集不可能になっていたりします。
InitializeComponent()以外で追加したコントロールをデザイナ上で操作することは不可能なのでしょうか？ VBで作ったシステムをVB.NETに移植しようとしたが
あまりも超絶スパゲッティだったのでほぐしたら
最終的にコード量が1/4になった事がある VB6で長年熟成された秘伝のソースをぽっと出のVB.netごときで再現できるわけがない VBのツールいまだに動くからリプレイスする意味ない
放置が安全 要するに5年ぐらい前に言ってたはずの「Win32を全廃してUWPで一本化する」計画は
諦めたってこと？
まああの話も一瞬出ただけでその後まったく聞かなくなってたけど
>>798
アクセスレベルがprivateになってるとかではなくて？
っていうか、もしコントロールをユーザーコードで追加している場合だけ起こる（デザイナで追加した場合は起こらない）
問題だと分かっているなら変なこだわりを捨てればよいだけなのでは？
まあバグでプロパティがいじれないコントロールも一部あるらしい
https://teratail.com/questions/236012 デザイナはわりと属性見てるので、その辺ちゃんとやっとかないとうまくいかないことがある winフォームアプリなのですが、Form1上のtextBox1に他クラスからアクセスしたい時って
Form1.Designer.csの下の方にあるフィールドをpublicに変えるのはよくない例ですか？
Form1のコンストラクタで自分自身を当該他クラスに引き渡す処理は済んでいます
Form1で、textBox1.TEXTをプロパティにして
他クラスからアクセスする方法も考えたんですけど、
じゃ、テキストボックスじゃなくてリストビューとかだとどうするんだとか考えたら
めんどくさいからもうpublicでいいんじゃないかとか思っちゃうんですけど
ベテランの皆さんはどうしてるんでしょうか >>809
俺はpublicにしちゃってる
ものすげー数があるときにいちいち仕組み作ってたらすごく汚くなっちゃったから
余計なことせずにpublicにしちゃったほうがよかった >>811
頑張って考えるまでもない。
XがFormを参照するんじゃなくて、FormがXを参照するように変えるだけ。
なぜUIの更新なんていう猿仕事を他のクラスにやらせようとするの？
それはUI自身の仕事だよ。 >>812
誘惑にかられますわ
>>813-815
カスタムコントロールとかですか？
ググっていろいろ調べたんですけど面白そうですねこれ
今回の用途にどう使うのかについてはまだ理解できてないですけど
継承ってこういうことに使うんですね
>>816
つまり、他クラスからForm1のtextBox1に書き込む仕様自体がおかしいってことですか
Form1から他クラスに仕事させて、結果をForm1で受けとってForm1からtextBox1に書き込むべきという理解でよいですか
確かにそうですね
他クラスから書き込むとForm1のコードがスッキリするので気に入ってたんですけどよくないってことですね
他クラスの汎用性を奪っているとも言えますね >>813-815
なんとなく分かりました
public partial class CustomTextBox1 : TextBox
こうやって定義してから、このクラスに処理のためのメソッドをおくとともに
自分自身のTextプロパティに書き込むようにしておく
で、このメソッドをForm1から呼んで処理させればボックスに書き込むことができるっていうことですね
あー勉強になりました >>815さんは違う提案でした
アクセス修飾子の話ですね
publicにする必要ないだろうということですね
なるほどです >>809
やり方は人それぞれなので何が良いとかないと思うけど、デザイナで操作できる
ところはデザイナで操作したほうが良いと思うよ
Designer.csをいじっても結果は同じなんだけど、おかしなコードを書くとデザイナの
挙動がおかしくなったりしてイランことに時間がかかったりするから 見掛けは同じように見えても、改行コードのせいでエラー吐いてたプロジェクトをなんとかしてくれと依頼されたことがある >>809
ってDesigner.csを直接編集することに疑念をもっているのか
コントロールをPublicにすることに疑念をもっているのかどっちなんだろ？ 空っぽのイベントハンドラを一発で消去する消去する方法は無いのでしょうか？ >>820
>>822
コントロールのアクセス修飾子をデザイナから変更できることをさっき知りました
そうすべきでした
元々の質問内容は、直接Designer.csを編集してもよいかどうかではなく、
publicにすること自体いいのか悪いのか、でした。 TextBox自体をpublicにするのはやっぱり微妙かなあ
自分だったらForm1クラスにpublic(or internal)なメソッドを作って、
メソッド名をTextBoxにアクセスする目的を明確に表す名前にする
たとえば、
void set合計金額Text(int price, Color textColor) { }
string get現在のその他欄入力値()
とか言った感じで あ、小文字始まりでJavaのsetter/getterみたいにしちゃったけどC#なら当然大文字始まり
受け取りたい項目が複数、例えポップアップ表示ダイアログの各項目の入力値を取り出すなら、
入力値を詰め込むInputValuesクラスとかを定義したうえで、
InputValues GetInputValues() { }
みたいなメソッドを作って入力値をオブジェクトで扱いやすくして返すようにする インデクサー作った方がスマートかな？
public var this[int i] >>826
やめろやめろ
そんなバカなことなれて
コントロールが300個とかあるときどうするんだ
〜するべきとかそもそも元の造りがそんなふうになってないことのが多いのに
無駄なラッピングなんてするべきじゃない
想定するならそれが1000個あるときそれをやってられるかどうかを想定しろ
そもそも少数ならアクセス方法なんてどうだっていいだろ？
想定してるのは大量にある時なんだよね？ >>829
何で勝手に膨大な数のコントロールがある前提なんだ？
質問者はそんなこと全く言ってないし、読んだ限りでは初心者が小規模なプログラムを作ってる可能性の方が高そうだ。
そういう相手に実務上の仕方なくやる汚いやり方を教えるより、場合によっては理想論になるかもしれないが基本的に良いとされる考え方をまず教えた方がいいだろう。 ？？？
おおもとの>>809では対象はtextBox1の一つだけみたいだけど
でこれがTextBoxからListViewに変わったときとかの話はあるけど
対象項目が大量なんて前提はどこから湧いてきたんだっけ？
というか１画面にコントロールが300個とか1000個とか配置されてて、
全部publicフィールドになってて、法則性もなくあらゆるコントロールに無尽蔵にアクセスする
なんて、その時点でソースから腐臭が漂ってるよ
そこまで酷い状態になってるなら諦めて全部publicにするしかないでしょう
後日メンテナンスしなきゃならないときの影響調査で死ぬだろうけど >>809
Viewのインターフェースを決めてFormで実装
他のクラスにはViewのインターフェースを渡す
他のクラスはFormの詳細には興味がない >>826のラッピングが無意味で有害無益なのは>>829の言う通りで、
問題点をはっきりさせるために大量のコントロールがあるケースを想定するのも間違ってない。
だからと言って>>812にあるようにコントロールをpublicにするのもダメ
OOP的な考え方もカプセル化の意味も分かってない人がこうも大量にいるのは困っちゃうねw >>830
良くないじゃん
だってお前のやり方は数が増えたら手間ばっかり増えて何のメリットもないし
数が少なければ見通しが効くからラッピングなんかいらないわけで
この世に必要ないことしてんだよ >>834
何の理由？
つーかこのレベルの話が分からん人は回答する側に回ったらダメだろうさすがにw >>837
だから、それって「どうしてカプセル化なんて必要なの？」って聞いてるのと同じだよw
カプセル化が重要なのは人間の脳が複雑性に対して脆弱だから。
だから必要な物だけ見せてそうでないものは見せないことによって複雑性を減らす必要がある。
例外はあるが、基本的にはUIはメンバーを外部に公開する必要がない。
表示を更新するのも、ユーザー入力をモデルに伝達するのも全部それはUIの仕事。
それを他人にやらせようとする発想が根本的に間違っている >>838
複雑になんねーよ
text一個だって
数が増えたらお前の仕組みは邪魔で邪魔でいらねーんだよ
だから、この世に必要ないことしてんだよ
って言ってんだよｗ >>838
カプセル化を考えるからこそ、publicにするかどうかを悩むんじゃね？
カプセル化が頭になければ、悩まないで全部publicにしちゃうだろ UIスレッド以外のスレッドから操作されると危険だよね、単純にコントロールを公開すると。 コントロールに直接アクセスを許すんじゃなくて根っこにあるデータへのアクセスを許すようにしとけばいいんじゃね？
コントロールとデータはBindingしてんだからそれでいいだろ WinFormsだからバインディングはしてないとおもう >>841
それはフォームにメンバを追加してラップしたところで解決にならん
フォーム自身がコントロールとして元々持っている大量のメンバはどうするんだ？
もしスレッドセーフにしたいのならフォーム自体も公開してはいけない >>846
そんな大げさな話？
コントロールへのアクセスはFormの仕事だから他人にやらせようとせずにForm自身にやらせろと言っている。
これのどこがそんな難しい話？
ファミレスで客が厨房に乗り込んで注文出さないのと同じことだよ
注文を受けるのはウェイトレスの仕事
パスタの担当が厨房の佐藤さんであることを客が知ってないとナポリタンの注文を
出せなようなファミレスにあんた行きたいか？w >>848
ウェイトレスがいるレストランが正しいのか、セルフサービスの定食屋が正しいのかの議論に見える
つまり、どちらも正しくて、ケースバイケースで選ぶのが正しい ぶっちゃけアーキテクチャパターンと規模次第
MVVM、MVU、MVCの場合はVの機能をV以外に公開することは滅多にない
MVPでは逆にVの基本的な機能をインターフェースで抽象化して積極的にPに公開してコントロールを委ねる
Formの主力アーキテクチャはどうなっているかというとMVPのVPが結合した怠惰なアーキテクチャになってる場合が非常に多い
丁寧に作るならPに書くべきコードが手抜きされてVのFormイベントに書かれてしまっている状態
VPが結合してるからprivateなコントロールを抽象化しなくてもアクセスすることはできる
しかしそれでは規模が大きくなるほどメンテナンスしにくくなる
VPが結合していても基本的な機能を抽象化しておくと後々のメンテナンスが楽になる
このような自クラス内部に向けて抽象化された安全なインターフェースを提供する開発手法を自己カプセル化と言う 規模が小さい練習用のアプリなら>>826 の言ってるように組むと思うけどな。なにが問題なんだ >>849
そういう問題じゃない
注文相手がウェイトレスだろうと厨房にいる店主のオッサンだろうと、客がすることは「注文を店の人に伝える」だ
その注文を受けて店がどうするかという実装の詳細は知ったことではない
ケースバイケースで判断するべきは、そのフォーム同士のやり取りが客と店の間で行われるのか、それとも店の中で行われるのか、という点
後者なら例えばウェイトレスが厨房の設備のレイアウト等を知っていることを前提としてコックへ依頼をすることは店の規模次第では許されるし、そうしたほうが手っ取り早いケースは多いだろう
これは突き詰めると責任分界の問題で、フォームの役割や開発チームの構成等によって最適解は変わってくる そう言う実装がヤバいってのを
身を持って体験するのも勉強の一つじゃね？
初心者スレなんだし😅 客： 「すみませーん、注文お願いします」
店員：「注文はそちらのタブレットからお願いします」(NotImplementedException) >>853
初心者のうちに気づける失敗はどんどん経験させた方がいいと思うけど、今回の話みたいに、規模が小さいうちは悪手でも問題なくてそれに気づかず変な癖をつけてしまって、後になって大きな規模で問題に直面することもあるからちゃんと説明するのは大事だと思う。 >>851
規模が大きくなるほど抽象化が重要になる >>852
バイキング形式でもいいじゃん
店員いらんよな？ 朝バイキングあるような高級ビジネスホテルなんて泊まったこと無いな >>859
ドーミーインとか高級なの？
ビジネスホテルは温泉とか朝食ビュッフェついてる事優先で選ぶけどな。 >>860
東横インの朝食をバイキングと呼ぶかね？ 役に立たない議論と雑談をどれだけ続けるんだお前ら
マ板でやれ もう関数型言語だな
ジャパニーズドカタは完全に置き去り 遂に登場！コピーコンストラクタ
not とか and とか basic ぽい
でも is not はいいね
Covariant returns 個人的には欲しかった機能 .NET5に合わせる感じか
結構良い感じだけど付いていけない老害は騒ぐだろうな 便利になるのは嬉しいけど最近、他の言語の後追いが多くねえか？
async/awaitのときみたいな、C#すげえって感動をまた味わいたいものだ 何気にトップレベルで直接プログラムが開始できるの嬉しいな。
小さいスクリプト的な使い方で便利になるかもしれん。
dotnet run xxxx.csみたいに出来ると言うことないな。 >>872
個人的にはやり過ぎだと思うわ
コンパイルが不要になるわけじゃないしちょっと複雑なことしようと思ったら変数宣言も要るからあんまりメリットに思えない
スクリプトならPowerShellでお腹いっぱい CakeやC# Scriptがすでにあるしなぁ
Record周りの新機能といい、C#チームはTypeScriptを真似しようとしてるのかね 今時のWeb開発だとマイクロサービス指向で小物を沢山作ることが多くなってて、
振る舞いを色々備えててカプセル化とかもきっちりやったリッチなモデルよりも、単にデータクラスを関数で弄るだけみたいなスタイルが主流になりつつあるんだよ
Main省略もその文脈で言えば自然
最近のC#周りは完全にアメリカで主流な内製開発に迎合していて、日本のドカタには理解されにくいね >>873
コンパイルがまるで不要かのように振る舞わせたいんだと思うよ。
replできたり、dotnetコマンド見てると。
確かに、csxはどうしたいんだろうな。
個人的にはPowerShellは抵抗感あるかもしれん。 ■ このスレッドは過去ログ倉庫に格納されています
