自分で書いた治安の悪いJavaScriptの仕様をすっかり忘れていて、結果的に面倒なことになりかかっていた

書いたJavaScriptに汎用性がなかったため、(JavaScriptの仕様を) 思い出す前のコードにロールバックした

こんな雑コードで動くと知って唖然としている ((int+int)+stringの結果がstringになっている)

データをどの程度サニタイズすべきなのかという問題がですね

リストに格納した自分で作ったクラスの中の、任意のプロパティをメソッドの外から指定してアクセスしたいがためにドチャクソ汚いコードになった
(List<T>名).GetType().GetProperty((メソッドの外から指定しているプロパティ名)).GetValue((List<T>名)).ToString()

@hadsn 表示のためだけにVMにObservableCollectionを置く。Modelには同じデータをソートしやすい形で置いて、ソートを終わらせたらObservableCollectionを全部入れ替える。
INotifyCollectionInfoを自分で実装するとより速いけど最初はやめといた方がよさそう

@204504bySE List<T>からObservableCollectionを作り上げてバインドし直そうとしたら、謎の例外 (空のObservableCollectionをバインドしたときには起きなかった例外) を吐いて詰んでるのが今

@204504bySE なお、これらの記述は何も判らないままにコードビハインドに書かれてるものとする (地獄か)

@hadsn DiscordでVisual Studio配信するしかない

@204504bySE こ、構造的に分離されていればファイルを分けるのも簡単ですし(白目)

@hadsn その前にDiscord配信できるスペックのPCが必要だった

@204504bySE せやで(ﾆｯｺﾘ)

@hadsn WPFはエラーメッセージを出力しながらも限界までしれっと動こうとする傾向にあるので、実行時の出力ウィンドウをよく見ること。
WPFでよくハマるのが、bindingする各要素は全部プロパティ(get, 必要ならsetも)にする必要があるやつ。

@204504bySE カラム自動生成時の、カラムの位置設定がおかしいって出るのよねえ (index範囲が超えている)

@204504bySE ﾃﾞｽｶｰ(白目)

@hadsn MVVMでは、VMは何列目に何が表示されてるか知らずに済むのが理想の姿だったりする。知るとしてもカラムの入れ替えを保存する為だけだね。

@204504bySE 確かにViewだけが知ってしかるべき、という感じではある

@hadsn 単なる値の入れ物ならDictionaryの方がマシな気はする。とはいえ構造にもよるしなあ。