WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Windows Presentation Frameworkについて語るスレ。
前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part20
http://echo.2ch.net/test/read.cgi/tech/1458082648/
関連スレ
Windows 10 UWPアプリ開発
http://echo.2ch.net/test/read.cgi/tech/1440150886/
コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/ >>586
お前んとこよ業務システムはスマホOnlyかよｗｗｗ >>585
vb6の業務システムを泣きながらWindows10対応している俺の立場は。
なーんもしなくてもそのまま問題なく動いてるっぽい(ーー;) VB6はドトネトより明らかに早いから、しっかり作ってあるとWinFormsなど見た目で差別化が出来ない場合辛いものが有るね
まあメンテするこっちからみたらクソ言語では有るが アプリケーションは速ければ速いほど良い。
vb6ってこんなに軽かったっけって思うよ。
でもこんな仕事はいやズラ(T_T) いくら速くてもメモリリークするようなゴミでは使い物にならない
やっぱりWPFだな
GdiplusStartup と GdiplusShutdown を繰り返すとメモリ リークする
https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2017/10/10/gdiplus-tsf-memleak/
＞現在、この問題を修正する予定がありません。 いくらメモリーリークしなくても日が暮れる前に仕事を終えてくれないとなー gdi++の初期化/終了なんぞ頻繁に呼び出すことはないからどうでもええけど
それより原因となるTSFのリーク発生条件がやべえな
ダミーウィンドウと共にスレッド起こすのは小細工としてそこそこ出番があるような >>597
思いっきり当てはまる作りをしているアプリがあるわ。
生成頻度は少ないからまぁ大丈夫だろうけども。 DatetimepickerってWPFに無いんだ…
日付と時間表示どうすんの… 今アフリカでは飢えた子供たくさんいます。皆さんの寄付をお待ちしております。 >>602
スピンも無いぞw
Extended WPF Toolkitを使え >>599
ぼっても割に合わん。
動作不良じゃなく元々のバグがかなりあるOrz
当時のブビプログラマーのレベルはこんなもんだがw >>532
最初の敷居はちょいと高いかもだが
このフレームワークの考え方に慣れたら便利だよ mvvmやxaml,データーバインディングは作りたいアプリがあったので作りながら覚えれたけど、次のステップとしてリアクティブプログラミングやろうとしたがリアクティブはかなり敷居高そうだな WinFormsでカスタムコントロール作ってオーナードローした人じゃないと
wpfの有り難みは理解できんかもな
そりゃコントロール並べるだけならwinfromsのほうが遥かに簡単だ 少なくともWordが使いこなせないとxamlは無理ね。 なんでコントロール並べるだけのことが後発のWPFでは難しいんだろうな
WinFormsでできることがXAMLを一切触らずにがUIデザイナでできたら、
結果は違ったんだろうか？ >>609
ReactiveProperty/ReactiveCommandの話なら、すごく楽だよ。
逆に今までの苦労は何だったのかと思うほど。 uwpでReactiveCommand使う時、disposeのタイミングで例外吐く不具合があってエライ目に有ったんだが
アレは治ったんだろうか？ 遅いらしいし、コントロール揃ってないし、なんかめんどくさそうだし、将来WPFが
主流になるんだったら覚えてもいいけど、まあもうちょっと枯れてからでいいやと
思い続けてとうとう今日に至る winfromやwindows7で困ってない人を移行させるのは難しい。
それ以前に移行すると困る人が大勢いるのはMSの怠慢と言わざるをえない。 Java案件にはデスマが待っている。関わりとうない、関わりとうない♪ >>613
それは、ある程度使えるようになってからだろ？
その前段階の覚える段階の敷居が（目標がないと）高いって意味じゃね？ >>624
prismなんかで組んでいるようだから、２，３０分も有れば基本的なことは出来るよ xamarinがwpf/mac/gtk#にも対応するようなのでいよいよ本当に終わりですか MVVMが全く理解できん
プログラミング初心者には無理な壁か… >>629
先ずはビューモデルとバインドから。
イベントはベタ書きでもおっけ。 個人開発の規模だと、ビューとモデルを分割する事のメリットからしてあまり感じられないだろうから無理も無い VとVMの切り分けはよく分かるんだけど
VMとMの切り分けがよく分からないんだよね
データがRDBにあるとして
VMでSQL書くのはMVVM的にNG？ prism.UnityとかAutofac等のDIコンテナ使うとMVVMの理解は深まるけど
DIコンテナの理解を深めないといけないという自転車操業 >>632
同じくVMとMの切り分けがあいまいになっている自分
RDBはビジネス要件だからどちらかというとModelとして切り離すべき テストコード書かないのなら分離しなくても問題ないでしょ。 設計者俺実装者俺利用者俺の3俺構造だとMVVMの恩恵はあまりない
一応恩恵あるけどスゲー便利というほどじゃない
どちらかというとObservableCollectionやMicro-ORMの理解の方が大事だと思う Viewの部分入れ変えても大丈夫な程度にしておけばいいと思う。 WPFに何を求めるか次第じゃないの?
MVVMとしての美しさを求めるか、単にUIとしての美しさを求めるか。
オレの場合はUIの美しさしか求めないんでMVVMはどうでもええ。 >>632,634
コンソールから使うコマンドラインアプリとして書いてみれば、何がModelなのか分かるよ
そのModelをGUIとかの特定のViewに合致させる役割がViewModel MVVMで作るときのソリューションのフォルダ構成どうしてますか？
Models/Views/ViewModelsの下にPages/UserControlsなどを置くか、その逆にするかで迷う。 >>642
機能で分ける
M/V/VMは区別しない
MVVMに限ったことじゃないけど、一般に、種類で分けるのはモジュール強度の低い良くない分け方だよ 迷うってことは、問題が解決してないってこと。つまり失敗した概念だと言えるな。 分けるというより、目障りだからどかす、というイメージが強い
意味合いが#regionに通じてるところがある >>642
xamlとVMは同じフォルダ内に置いてる。 データコンテキストってなんなの…
全然使い方がわからない…
WPFほんと難しい…自分の頭の悪さに引くわ… そんなとこで詰まってるならやめた方がいいんじゃない?
テンプレートバインディングや依存関係プロパティで死ぬよ ルーティングイベントとかクッソ意味不明
Adornerとかレイアウトイベントの使い分けとかDrawing系の低レベル描画層とかゲロ複雑すぎてやばい あと見た目の状態遷移に使うVSMも癖があって慣れるまでクソ難しい
WPFの場合は更にトリガとの使い分けもあってカオスの極み あとWIC系のAPIもヤバい
たかがビットマップイメージがなんでここまで複雑になるのか不思議なレベル >>648
すごく単純に言えば、バインディングに使用する複数の変数を任意の1つのオブジェクト(クラス)にまとめておくだけの機能だよ。
(各変数はそれぞれプロパティとして定義する) DataContextやDependencyPropertyは使ってりゃそのうち分かるようになるし
一度分かってしまえばどうということもない
VisualStateManagerは確かに難しい
つか使いこなせん
Styleのカスタマイズは未だに試行錯誤というか行き当たりばったりだわ >>653
んー…分からん…
色んなサイト見ても全部微妙に違ってどれを参考にしたら良いかもわからん
MVVMだとどの部分に書くんだ？ んー…なんというか…。書くとか書かないとかというか、、データソースなんだよ >>655
Contextって名前が曖昧すぎる。
DataHogeと同じで名前に意味はない。
DataContextにはViewModelのインスタンスを設定してDataCintext=ViewModelだと思ってればよいのだ。 >>648
難しいのは考え方だろうね
データコンテキストが難しいと感じるなら、根本的に発想の転換が必要なんだと思う WinForms時代のデータソースも分からない人だろ。 >>656
>>657
>>658
せっかく説明してくれてるのに理解出来なくてごめんよ…
元々プログラミング始めたばかりの自分にはハードル高いよな…
this.DataContext=table;
とかだとXAMLにBinding tableって指定してる所と紐づけるって解釈で良いのかな？
MVVMでアプリを作ってみてるんだけど、C#の言語自体の理解もまだまだだからすげぇ難しい…
this.DataContext=table;←これもModelクラスに書くべきなのかViewModelに書くのかよく分かってない
View→ViewModel→Modelって関係になっててV,VMとMは切り離して考えるのは分かるんだけど、例えばModelクラスに書いてる処理(例えばデータベースの値をDataGridに表示させるとか)をどうやってViewModelから取得したらいいの？
プロパティとか使うの？ >>661
それは Xamlには Binding だけでいい 知識ないうちはXamlは地獄
知識あってもタイプミスとかでデバッグがものすごくつらい
いろいろ無駄なことをさせられる 俺の理解ではDataContextはBinding SouceとBinding Targetのつなぎ目
DataContextを設定してはじめてSouceとTargetは赤い糸で結ばれる >>661
細かいことは省略した大雑把な例だけど、
class Table
{
int A { set; get; }
int B { set; get; }
}
this.DataContext=new Table();
と設定しておくと、{Binding Path=A}とか{Binding Path=B}って書けるようになる。("Path="は省略可) >>661
まず、データベースとか関係なくDataGridに何か(例えば1〜10)を表示することを考える
そうするとModelは必要ないからViewModelに全てを書く
ViewModelがViewのために1〜10を教えてあげるとViewはViewModelの言うがまま表示する
このことをViewModelにdatabindingしていると呼ぶ
しかし、いつも1〜10を表示しても何の役にも立たない
目的に応じて適切な値を表示したい
この1〜10ではなく目的に応じた適切な値を管理するのがModelの役割
例えば、データベースから31415926534とか取ってきたりする >>661
ビューモデルとデータコンテキストの紐付けはxamlの中に記述する。
xamlはhtml見たいな画面記述言語じゃなくてc#(.net)のインスタンスを記述する言語。 >>661
>どうやってViewModelから取得したらいいの？
プロパティとか使うの？
バインドさせる。 >>667
>xamlはhtml見たいな画面記述言語じゃなくてc#(.net)のインスタンスを記述する言語。
それXAML一般じゃなくてWPF限定だから気をつけた方がいいよ
UWPやSilverlightでは.NETオブジェクトはアンマネージドなXAML DOMのラッパー
だからC#でツリー組むよりXAMLをテキストで読ませたほうが速かったりする >>669
そうなの?
じゃ、UWPのxamlとWPFのではかなり別もんなのか >>669
それじゃUWPのobjフォルダに有る xxx.g.csファイルって一体何だ？ 一発目でwpfはツレーだろうな。理解していることの前提要素が多すぎる 素直にWinFormsで入門すればよかったのにw
C#に限らず今時のプログラミング言語自体、まったくの初心者にとっては躓きそうな要素が
色々あるのに、xamlがーとかMVVMがーとか言い出したら、地雷原を素足で歩くようなもの >>674
ConsoleでHello,world からでしょ。 ほんとそれな
Viewの前にModelの作り方、GUIの前にCUIの作り方覚えろと 今時CUIはないでしょう。
モチベーションが続かないし、Windows FormでポトペタでGUI作るより
CUIの方が簡単とも思えない >Windows FormでポトペタでGUI作るより
いきなりそれからやろうとすると、基礎が身に付かんだろって話なのよ
言語の基本仕様くらい真面目に学習せんかーい >>678
じゃあ聞くけど、CUIを選択することで学習できる基礎って何？
そんなものはないよ。あるなら言ってみ？
そういう話なら、たぶん構造化プログラミングをすっ飛ばしていきなり
クラスベースのOOPに挑戦する弊害の方が大きいと思う CUIは入出力がものすごく単純でGUIみたいなフレームワークの知識がほぼいらないので言語の仕組みそのものに学習を集中できる >>679
MVVMのModelで実行できるプログラムにGUIって必要か? ぶっちゃけ、GUIやConsoleプログラムのI/Oって泥臭い処理で
プログラムの本質を学ぶ上では必要の無いものなのかもね。 >>684
cursesみたいに複雑にしようと思えばいくらでもできるけど、printfとscanfだけでも最低限のものは作れるでしょ
GUIだとその最低限のものを作るのにも書かなきゃいけないことが多くて初心者向きじゃない ボタン押してラベル書き換えるぐらいもやる気がないなら
プログラムやる資格はないと思う >>ボタン押してラベル書き換えるぐらい
のことでもViewのコードビハインドにするかViewModelとの相互作用にするかでも悩まされるのがWPF
ViewModelとの相互作用で書いた方が可搬性があがるよ！
…分かるけど、それ、初心者向きかしら？そんなことも思わすのがWPF ■ このスレッドは過去ログ倉庫に格納されています
