ふらっと C#,C♯,C#(初心者用) Part144
レス数が1000を超えています。これ以上書き込みはできません。
!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと(1行分は消えて表示されない為)
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■関連スレ
C#, C♯, C#相談室 Part95
https://mevius.5ch.net/test/read.cgi/tech/1508168482/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■前スレ
ふらっと C#,C♯,C#(初心者用) Part143
https://mevius.5ch.net/test/read.cgi/tech/1558002486/
■情報源
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/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >>915
サンプルのjsonを添付してここを変更しろとドキュメント付けとけば問題ない
インデントが変わっても問題ないし >>912
俺はDataContractJsonSerializerだな
これなら標準ライブラリだからインストール不要 >>916
jsonはカッコの対応で死ぬわ
っていうかxmlもjsonもiniファイル駆逐できるほど性能よくねーじゃん
っていうか用途が違うものを強引に適用しようとしてない?
設定ファイルに書いたコメントも消えちゃうしね iniファイルを時代遅れだと主張するなら
xmlやjsonで吐き出して設定ツールぐらい用意しろってことかな?
それなら理解できるけど
xmlとjsonのテキスト編集はキツイ ユーザーがやることはjsonの値をちょい変更するくらいなのになんでカッコ対応が問題になるんだよ
ユーザーがカッコを書く必要なんてないのに >>921
いや、だからそれどこよ?
ってのを見つけるのも結構骨が折れる作業よ
だから、コメントをjsonファイルに書いておくだろ?
ところが次のアプリの書き込みで消えてるんだなw 話はよーわからんが、JSONに慣れれない人もそれがあんたの能力なんだから
しょうがないんじゃない >>922
ちゃんとしたエディターかIDE使えば?
VScode使えば対応簡単だけど
まさかメモ帳でやってんの? そもそもバグったときに凶悪であることは認めるだろ?
俺らだってxmlやjsonファイルでユーザーが編集したおかしな箇所を
プログラムでピンポイントで指摘できない
このファイルは完璧でないと読めない
そんなモノをユーザーに触らせるような運用は間違っている
客がいいって言うならいいけど vscodeとかtsとかnode.jsとか設定はjsonだけど
それで大問題にはなってない
みんな使いこなしてる
何故君だけ使えない?
iniファイルなんて実際死んでるよ? >>927
客がなんでjsonファイルいじって中にコメント書くのかが分からん
お前がいつまでボケ続けるのか興味があるが… 本当にいつまでボケ続けるのか
実務に携わってないんだろうなってのはわかる
空転を本人が気づいてない よく出てくくる、一本道コードのVisual Basicおじさんでしょ はっきりさせておくけど
・設定ファイルをテキスト編集でユーザに触らせたい
→xmlやjsonは向かないんじゃない?
・設定ファイルをユーザに触らせない
→なんでもいいんじゃない?
ってことな あともう一つ
・ユーザは開発者である
→なんでもいいんじゃない
って感じな ・設定ファイルをテキスト編集でユーザに触らせたい
の時点で間違ってる
バックアップすら取るかどうかわからんやつらに編集させんな馬鹿 >>914
なるほど、これはもうjson.netいれるしかないですね
>>918
MS謹製のJson、これはかなりとっつきやすそうさんくす ボケた会社の〜ボケた開発者が〜ボケた客にボケたことをさせて〜
メンテナンス費用だけとるつもりですか〜
死ね糞ゴミ! でも、初心者なのに仕事を取ってくる勇気は大したもんだよね >>933
俺なら
>・設定ファイルをテキスト編集でユーザに触らせたい
→そんな仕様にはしない
なぜならあらゆるフォーマットに対応する実装とテストなんてしたくないし
そもそも設定をテキスト編集するアプリとか使いにくい
>・設定ファイルをユーザに触らせない
→xmlにする
なぜなら実装が簡単だし、開発者(俺)ならテキスト編集できるから レガシーコードってなんかかっこいいから、どんどん増やすべき。
伝説の武器みたいなものでしょう。 >>936
2chだとやたらとJSON推しの人が多いけど、.NET標準のシリアライザは他にもいろいろあるよw
JSONに固執する必要がないなら他を検討した方がいいと思うけど JSONは連想配列に順序の保証がない
デバッグで差分比較するとかができない >>942
.NET標準でjson以外にほかにいろいろシリアイザがあるって、XML以外何かある? >>942
なるべくネット上に解説とかサンプル多いと楽かなっと
多数派に流されるお json schema用意すればvscodeで補完効くし、間違いも指摘してくれるし、普通json使うわ DataContractJsonSerializer、使ったことなかったが調べた感じ
一通りの機能はあるし、バージョントーレラントみたいだし、別にこれでもいいねw
バージョントーレラントじゃないと思ってたが、勘違いだったみたいだ。 トーレラントって何かググってみたけど中華鍋しか出てこない 確かにJsonはコメントが書けないか
コメント用の文字列メンバを予め確保すれば良いのかな jsonのシリアライザ/デシリアライザは送受同じライブラリを使わないと、割とめんどい。
DateTimeの扱いとか。
あとライブラリによってはpublicクラスじゃないとダメとか変な制限があるものも・・
DataContractJsonSerializerは変換遅いし、いちいち[DataContract]や[DataMember]などのアノテーションがめんどい 以前REST APIを作ったときはVisual Studioがjson.netを利用するコードを自動生成してたけど、今はDataContractJsonSerializer化されてるのかな? windows formsアプリについての相談なんですけれど、ロジックと見た目を分けろって聞くじゃないですか。なのでそうしようと思ったんです
例えばユーザーコントロールを作って、そこに何かしらの処理を行うボタンを配置したとします
それで自分が考えたのは、計算をするクラスをユーザーコントロールクラスの内部クラスとして作る、ユーザーコントロールクラスのフィールドとしてその計算するクラスのインスタンスを持たせる
でボタンが押されるイベントで計算をするクラスのオブジェクト.calculate()みたいにする
設計としてはこんな感じでも大丈夫ですかね?アプリを作る時に内部のコードはこう実装するみたいなことを教えてくれる本が無くてどう設計していけばいいのかわからないんです 右も左もわからないうちから俺俺アーキテクチャとか考えないで
MVCやMVVMでも勉強したらいいと思うよ
それから最強のアーキテクチャを考えるのでも遅くない >>956
>ロジックと見た目を分けろ
windows formsアプリじゃなくWPFやった方がいいんじゃない?
windows formsでそんな組み方するの逆にめんどくさい >>955
cjsonはわかりやすいのかな、ちょっとしらべてみるさんくす >>956
そんなことしなくて良い
画面アプリなんて使い捨て上等
サーバーサイドと画面(クライアント)を分けろって話で
一つのアプリでそんなことやっても無意味 「既存メソッドの処理なんですが?ちょっと時間かかっちゃうんですよねー
プログレスバーとかつかないですかね?
処理の進行状況も表示して」
こんな簡単な要望ですら
そいつはケツまくって逃げ出すよ
花京院の魂を10000個ぐらいかけてもいい絶対だ
処理と表示は一見関係ないように見えて実は密接に関係していて
絶対に切り離せない
不可能なことを可能だと言う技術者を信用してはならない
何年もやっていてこの程度の因果関係もわからんような雑魚から
教えを請いてはならない >>956
何でユーザーコントロールの話になるのかよく分からんけど、
>ユーザーコントロールクラスの内部クラスとして作る
この部分は変だけど(内部クラスにする必然性がない)、その後の部分はそういう認識でいいと思うよ。
FormでもUserControlでも、基本的に書いていいのは上に乗ってる
コントロールを操作するコードとイベントハンドラだけ。 >>962
C#にはIProgress<T>というクラスもタスクも横断的に使える便利なIFがあるから
あんたが思っているようなことはない
つか、偉そうなのにこれ知らないのか? 自分は頭が悪すぎてIProgress<T>のどこが便利なのかわからないので
違う仕組みでやってる >>964
はぁ?
既存の何も考えずに作ったメソッド(内部)のプログレスバー(表示)を分離したまま実装できないだろってのが俺のレスの主旨なんだけど
理解した上で反論しようとしてんの?
Mr.ドン・キホーテ? >>966
いや、簡単に実装できるよ
君が知らないだけで >>967
あっそ、絶対無理なのにバカだなお前
テメーはさっさと技術者やめて詐欺師に看板替えろ 昔はイベントハンドラで実装してたな
いまならObservablePropertyあたりでやるんかねRxとかどうも上手く使えてる気がしない >>969
確かにmvvmだとReactiveProperyを上位に伝搬するのが楽だし俺もそうやっている
でもFormsの話のようだからIProgress<T>を出しました FormsだとしてもIProgressは不便だと思うよ ID:Ih3UpniZ0って昨日iniファイル以外認めないって主張してた御仁か
15〜20年くらい前のスキルしかもちあわせてない人でしょ
技術的なキャッチアップも人間性の向上も怠って年齢だけ重ねてる人だからこういう物言いしかできないんだろう
こういう人のいうことは表向きだけはいはいって聞いたふりして全部無視して問題ないよ ほっとくとイベントの参照が残ってるのでひとりでに消えなくなってしまう >>975
backgroundworkerを自前で作らずにformに貼って、イベントもデザイナから作るといいよ だからIProgressでメモリーリークするソース出せってば IProgressはインターフェースなんだからそれ自体がリークってのはおかしいでしょ。使い方が悪いだけでは…? オッペケは自殺して転生して自分の頭のバグ直してこいやボケ インターフェイスでメモリリークするわけがないはその通り
ただ単純なイベントハンドラベースだとうっかりメモリリークさせやすい
コンポジションなどで保持したままで寿命が違うと特にそう
c++だとメモリリークしやすいが使い方が悪い!ちゃんとつかえ!
という話で済まないので進化し続けてる
そのProgressというけど偽りでProgressと言う動作と何の関係もない
実際はどこからも使われないく自分で使うコードを書くだけなのでProgressである必要もない
どこが便利で使ってるのかさっぱりわからない 見返すとめちゃくちゃだけどIpregressは別にProgressに高度に特化されてないので
使う意味は薄いのではないか?
nさんがどう思うか知らないけど >処理と表示は一見関係ないように見えて実は密接に関係していて
>絶対に切り離せない
ちゃんと考えて設計してもそうなるなら、絶望的にセンスがないわ
おまえに不可能なことが技術的に不可能なこととは違うよ >>985
理解できないなら無理にレスしなくてもよい >>986
バカだろ
物理的に不可能だろ
既存処理にプログレスバー付けてみろよ IProgressというか、その実体のProgres<T>クラスは、普通に使えばメモリーリークなんか起こらないんだよな
イベントじゃなくてActionデリゲート使ってメンバ変数など使わずにローカル変数で定義して
処理を実行するたびにインスタンス作ればいいだけ
ラムダ使えない人はご愁傷さまとしか言えません >>993
外から複数のハンドラ指定して実行したい場合どうすんの?
Actionにどうやって渡す? それと
> 普通に使えばメモリーリークなんか起こらないんだよな
と
> イベントじゃなくてActionデリゲート使ってメンバ変数など使わずにローカル変数で定義して
> 処理を実行するたびにインスタンス作ればいいだけ
は矛盾してるよね? >>994
複数のアクションを実行するアクションを渡す >>995
サンプルぐぐっても、イベント使ったりクラスのメンバ変数にして使い回すって方が邪道じゃないかな? >>986
多分切り離すとか分離するの意味を根本から間違えて捉えてるんだと思うので無駄だよ。関心の分離の基本がわかってない このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 84日 11時間 11分 35秒 レス数が1000を超えています。これ以上書き込みはできません。