WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/05/09(火) 09:09:13.94

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/

**デフォルトの名無しさん** · 2017/10/10(火) 18:13:20.63

>>586
お前んとこよ業務システムはスマホOnlyかよｗｗｗ

**デフォルトの名無しさん** · 2017/10/10(火) 18:23:28.85

>>587
死ねよ

**デフォルトの名無しさん** · 2017/10/10(火) 18:27:52.56

>>589
それが職員の本音

**デフォルトの名無しさん** · 2017/10/10(火) 19:40:17.75

>>585
vb6の業務システムを泣きながらWindows10対応している俺の立場は。
なーんもしなくてもそのまま問題なく動いてるっぽい(ーー;)

**デフォルトの名無しさん** · 2017/10/10(火) 20:02:50.32

VB6はドトネトより明らかに早いから、しっかり作ってあるとWinFormsなど見た目で差別化が出来ない場合辛いものが有るね
まあメンテするこっちからみたらクソ言語では有るが

**デフォルトの名無しさん** · 2017/10/10(火) 20:16:48.02

アプリケーションは速ければ速いほど良い。
vb6ってこんなに軽かったっけって思うよ。
でもこんな仕事はいやズラ(T_T)

**デフォルトの名無しさん** · 2017/10/10(火) 20:49:55.22

いくら速くてもメモリリークするようなゴミでは使い物にならない
やっぱりWPFだな

GdiplusStartup と GdiplusShutdown を繰り返すとメモリリークする
https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2017/10/10/gdiplus-tsf-memleak/

＞現在、この問題を修正する予定がありません。

**デフォルトの名無しさん** · 2017/10/10(火) 21:03:07.74

>>594
これってそんなに頻度高いの？

**デフォルトの名無しさん** · 2017/10/10(火) 21:03:53.95

いくらメモリーリークしなくても日が暮れる前に仕事を終えてくれないとなー

**デフォルトの名無しさん** · 2017/10/10(火) 23:05:52.56

gdi++の初期化/終了なんぞ頻繁に呼び出すことはないからどうでもええけど
それより原因となるTSFのリーク発生条件がやべえな
ダミーウィンドウと共にスレッド起こすのは小細工としてそこそこ出番があるような

**デフォルトの名無しさん** · 2017/10/10(火) 23:15:47.61

>>597
思いっきり当てはまる作りをしているアプリがあるわ。
生成頻度は少ないからまぁ大丈夫だろうけども。

**デフォルトの名無しさん** · 2017/10/11(水) 03:31:53.05

>>591
掘”った栗

**デフォルトの名無しさん** · 2017/10/11(水) 09:39:19.59

>>539
デバッグしたい//

**デフォルトの名無しさん** · 2017/10/11(水) 10:10:09.73

DatetimepickerってWPFに無いんだ…
日付と時間表示どうすんの…

**デフォルトの名無しさん** · 2017/10/11(水) 10:44:22.63

今アフリカでは飢えた子供たくさんいます。皆さんの寄付をお待ちしております。

**デフォルトの名無しさん** · 2017/10/11(水) 10:57:59.00

>>602
スピンも無いぞw
Extended WPF Toolkitを使え

**デフォルトの名無しさん** · 2017/10/11(水) 12:00:31.23

>>603
https://fresh.lawson.jp/goods/70999

**デフォルトの名無しさん** · 2017/10/11(水) 14:15:19.34

>>599
ぼっても割に合わん。
動作不良じゃなく元々のバグがかなりあるOrz
当時のブビプログラマーのレベルはこんなもんだがw

**デフォルトの名無しさん** · 2017/10/11(水) 17:54:00.03

>>532
最初の敷居はちょいと高いかもだが
このフレームワークの考え方に慣れたら便利だよ

**デフォルトの名無しさん** · 2017/10/11(水) 19:06:58.99

慣れたら便利は不便ってviで学んだ。

**デフォルトの名無しさん** · 2017/10/11(水) 19:31:07.43

不便じゃないがxamlは微妙だわさ

**デフォルトの名無しさん** · 2017/10/11(水) 19:44:00.46

mvvmやxaml,データーバインディングは作りたいアプリがあったので作りながら覚えれたけど、次のステップとしてリアクティブプログラミングやろうとしたがリアクティブはかなり敷居高そうだな

**デフォルトの名無しさん** · 2017/10/11(水) 19:45:55.55

WinFormsでカスタムコントロール作ってオーナードローした人じゃないと
wpfの有り難みは理解できんかもな
そりゃコントロール並べるだけならwinfromsのほうが遥かに簡単だ

**デフォルトの名無しさん** · 2017/10/11(水) 19:51:44.60

少なくともWordが使いこなせないとxamlは無理ね。

**デフォルトの名無しさん** · 2017/10/11(水) 19:55:42.90

なんでコントロール並べるだけのことが後発のWPFでは難しいんだろうな

WinFormsでできることがXAMLを一切触らずにがUIデザイナでできたら、
結果は違ったんだろうか？

**デフォルトの名無しさん** · 2017/10/11(水) 20:14:17.44

>>609
ReactiveProperty/ReactiveCommandの話なら、すごく楽だよ。
逆に今までの苦労は何だったのかと思うほど。

**デフォルトの名無しさん** · 2017/10/11(水) 20:26:19.51

uwpでReactiveCommand使う時、disposeのタイミングで例外吐く不具合があってエライ目に有ったんだが
アレは治ったんだろうか？

**デフォルトの名無しさん** · 2017/10/11(水) 21:11:58.60

遅いらしいし、コントロール揃ってないし、なんかめんどくさそうだし、将来WPFが
主流になるんだったら覚えてもいいけど、まあもうちょっと枯れてからでいいやと
思い続けてとうとう今日に至る

**デフォルトの名無しさん** · 2017/10/11(水) 21:19:31.21

>>615
10年経っでるのに枯れてないとな。

**デフォルトの名無しさん** · 2017/10/11(水) 22:29:17.19

winfromやwindows7で困ってない人を移行させるのは難しい。
それ以前に移行すると困る人が大勢いるのはMSの怠慢と言わざるをえない。

**デフォルトの名無しさん** · 2017/10/12(木) 10:14:35.23

アスペのすきなC#

**デフォルトの名無しさん** · 2017/10/12(木) 10:27:32.93

奴隷の好きな言語は?

**デフォルトの名無しさん** · 2017/10/12(木) 12:10:11.06

Java

**デフォルトの名無しさん** · 2017/10/12(木) 12:20:51.67

Java案件には関わりとうない

**デフォルトの名無しさん** · 2017/10/12(木) 12:46:50.56

アスペが釣れる

**デフォルトの名無しさん** · 2017/10/14(土) 08:02:49.68

Java案件にはデスマが待っている。関わりとうない、関わりとうない♪

**デフォルトの名無しさん** · 2017/10/15(日) 10:50:00.14

>>613
それは、ある程度使えるようになってからだろ？
その前段階の覚える段階の敷居が（目標がないと）高いって意味じゃね？

**デフォルトの名無しさん** · 2017/10/15(日) 11:14:02.79

>>624
prismなんかで組んでいるようだから、２，３０分も有れば基本的なことは出来るよ

**デフォルトの名無しさん** · 2017/10/16(月) 04:26:03.95

xamarinがwpf/mac/gtk#にも対応するようなのでいよいよ本当に終わりですか

**デフォルトの名無しさん** · 2017/10/16(月) 06:45:42.59

あの人達キモいからヤダ

**デフォルトの名無しさん** · 2017/10/16(月) 09:15:22.42

チンポ騎士団員は帰っていいよ

**デフォルトの名無しさん** · 2017/11/02(木) 09:54:27.69

MVVMが全く理解できん
プログラミング初心者には無理な壁か…

**デフォルトの名無しさん** · 2017/11/02(木) 10:01:40.38

>>629
先ずはビューモデルとバインドから。
イベントはベタ書きでもおっけ。

**デフォルトの名無しさん** · 2017/11/02(木) 10:14:35.62

個人開発の規模だと、ビューとモデルを分割する事のメリットからしてあまり感じられないだろうから無理も無い

**デフォルトの名無しさん** · 2017/11/02(木) 10:18:50.35

VとVMの切り分けはよく分かるんだけど
VMとMの切り分けがよく分からないんだよね

データがRDBにあるとして
VMでSQL書くのはMVVM的にNG？

**デフォルトの名無しさん** · 2017/11/02(木) 10:50:49.04

prism.UnityとかAutofac等のDIコンテナ使うとMVVMの理解は深まるけど
DIコンテナの理解を深めないといけないという自転車操業

**デフォルトの名無しさん** · 2017/11/02(木) 11:08:24.23

>>632
同じくVMとMの切り分けがあいまいになっている自分
RDBはビジネス要件だからどちらかというとModelとして切り離すべき

**デフォルトの名無しさん** · 2017/11/02(木) 12:34:30.50

テストコード書かないのなら分離しなくても問題ないでしょ。

**デフォルトの名無しさん** · 2017/11/02(木) 12:50:22.73

設計者俺実装者俺利用者俺の3俺構造だとMVVMの恩恵はあまりない
一応恩恵あるけどスゲー便利というほどじゃない
どちらかというとObservableCollectionやMicro-ORMの理解の方が大事だと思う

**デフォルトの名無しさん** · 2017/11/02(木) 18:47:26.55

Viewの部分入れ変えても大丈夫な程度にしておけばいいと思う。

**デフォルトの名無しさん** · 2017/11/03(金) 09:44:58.25

WPFに何を求めるか次第じゃないの?
MVVMとしての美しさを求めるか、単にUIとしての美しさを求めるか。
オレの場合はUIの美しさしか求めないんでMVVMはどうでもええ。

**デフォルトの名無しさん** · 2017/11/03(金) 09:52:50.24

>>632,634
コンソールから使うコマンドラインアプリとして書いてみれば、何がModelなのか分かるよ
そのModelをGUIとかの特定のViewに合致させる役割がViewModel

**デフォルトの名無しさん** · 2017/11/03(金) 09:56:57.17

アプリの規模にもよるかな

**デフォルトの名無しさん** · 2017/11/03(金) 10:02:02.08

画面作るのはXAMLが楽で良いなぁ。

**デフォルトの名無しさん** · 2017/11/04(土) 07:58:35.78

MVVMで作るときのソリューションのフォルダ構成どうしてますか？

Models/Views/ViewModelsの下にPages/UserControlsなどを置くか、その逆にするかで迷う。

**デフォルトの名無しさん** · 2017/11/04(土) 08:15:23.15

>>642
機能で分ける
M/V/VMは区別しない
MVVMに限ったことじゃないけど、一般に、種類で分けるのはモジュール強度の低い良くない分け方だよ

**デフォルトの名無しさん** · 2017/11/04(土) 08:19:20.77

迷うってことは、問題が解決してないってこと。つまり失敗した概念だと言えるな。

**デフォルトの名無しさん** · 2017/11/04(土) 08:46:00.62

分けるというより、目障りだからどかす、というイメージが強い
意味合いが#regionに通じてるところがある

**デフォルトの名無しさん** · 2017/11/04(土) 08:53:48.77

たしかにViewにプラスで必要な部分は迷うわ

**デフォルトの名無しさん** · 2017/11/04(土) 09:11:02.86

>>642
xamlとVMは同じフォルダ内に置いてる。

**デフォルトの名無しさん** · 2017/11/05(日) 23:23:33.87

データコンテキストってなんなの…
全然使い方がわからない…
WPFほんと難しい…自分の頭の悪さに引くわ…

**デフォルトの名無しさん** · 2017/11/05(日) 23:37:19.03

そんなとこで詰まってるならやめた方がいいんじゃない?
テンプレートバインディングや依存関係プロパティで死ぬよ

**デフォルトの名無しさん** · 2017/11/05(日) 23:42:44.11

ルーティングイベントとかクッソ意味不明
Adornerとかレイアウトイベントの使い分けとかDrawing系の低レベル描画層とかゲロ複雑すぎてやばい

**デフォルトの名無しさん** · 2017/11/05(日) 23:50:24.22

あと見た目の状態遷移に使うVSMも癖があって慣れるまでクソ難しい
WPFの場合は更にトリガとの使い分けもあってカオスの極み

**デフォルトの名無しさん** · 2017/11/05(日) 23:57:03.43

あとWIC系のAPIもヤバい
たかがビットマップイメージがなんでここまで複雑になるのか不思議なレベル

**デフォルトの名無しさん** · 2017/11/06(月) 01:08:49.29

>>648
すごく単純に言えば、バインディングに使用する複数の変数を任意の1つのオブジェクト(クラス)にまとめておくだけの機能だよ。
(各変数はそれぞれプロパティとして定義する)

**デフォルトの名無しさん** · 2017/11/06(月) 02:23:58.85

DataContextやDependencyPropertyは使ってりゃそのうち分かるようになるし
一度分かってしまえばどうということもない

VisualStateManagerは確かに難しい
つか使いこなせん
Styleのカスタマイズは未だに試行錯誤というか行き当たりばったりだわ

**デフォルトの名無しさん** · 2017/11/06(月) 13:12:40.27

>>653
んー…分からん…
色んなサイト見ても全部微妙に違ってどれを参考にしたら良いかもわからん
MVVMだとどの部分に書くんだ？

**デフォルトの名無しさん** · 2017/11/06(月) 13:38:43.96

んー…なんというか…。書くとか書かないとかというか、、データソースなんだよ

**デフォルトの名無しさん** · 2017/11/06(月) 13:55:11.78

>>655
Contextって名前が曖昧すぎる。
DataHogeと同じで名前に意味はない。
DataContextにはViewModelのインスタンスを設定してDataCintext=ViewModelだと思ってればよいのだ。

**デフォルトの名無しさん** · 2017/11/06(月) 18:15:34.67

>>648
難しいのは考え方だろうね
データコンテキストが難しいと感じるなら、根本的に発想の転換が必要なんだと思う

**デフォルトの名無しさん** · 2017/11/06(月) 18:26:51.77

WPFが流行らなかった縮図を見ているかのようだ…

**デフォルトの名無しさん** · 2017/11/06(月) 22:34:37.38

WinForms時代のデータソースも分からない人だろ。

**デフォルトの名無しさん** · 2017/11/06(月) 22:42:59.34

>>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から取得したらいいの？
プロパティとか使うの？

**デフォルトの名無しさん** · 2017/11/06(月) 23:48:48.36

>>661
それは　Xamlには　Binding　だけでいい

**デフォルトの名無しさん** · 2017/11/06(月) 23:51:37.56

知識ないうちはXamlは地獄

知識あってもタイプミスとかでデバッグがものすごくつらい
いろいろ無駄なことをさせられる

**デフォルトの名無しさん** · 2017/11/07(火) 00:02:15.24

俺の理解ではDataContextはBinding SouceとBinding Targetのつなぎ目

DataContextを設定してはじめてSouceとTargetは赤い糸で結ばれる

**デフォルトの名無しさん** · 2017/11/07(火) 01:05:32.39

>>661
細かいことは省略した大雑把な例だけど、
class Table
{
　int A { set; get; }
　int B { set; get; }
}
this.DataContext=new Table();
と設定しておくと、{Binding Path=A}とか{Binding Path=B}って書けるようになる。("Path="は省略可)

**デフォルトの名無しさん** · 2017/11/07(火) 01:51:17.40

>>661
まず、データベースとか関係なくDataGridに何か(例えば1～10)を表示することを考える
そうするとModelは必要ないからViewModelに全てを書く
ViewModelがViewのために1～10を教えてあげるとViewはViewModelの言うがまま表示する
このことをViewModelにdatabindingしていると呼ぶ
しかし、いつも1～10を表示しても何の役にも立たない
目的に応じて適切な値を表示したい
この1～10ではなく目的に応じた適切な値を管理するのがModelの役割
例えば、データベースから31415926534とか取ってきたりする

**デフォルトの名無しさん** · 2017/11/07(火) 06:48:36.59

>>661
ビューモデルとデータコンテキストの紐付けはxamlの中に記述する。
xamlはhtml見たいな画面記述言語じゃなくてc#(.net)のインスタンスを記述する言語。

**デフォルトの名無しさん** · 2017/11/07(火) 07:00:14.02

>>661
>どうやってViewModelから取得したらいいの？
プロパティとか使うの？

バインドさせる。

**デフォルトの名無しさん** · 2017/11/07(火) 09:12:12.63

>>667
>xamlはhtml見たいな画面記述言語じゃなくてc#(.net)のインスタンスを記述する言語。
それXAML一般じゃなくてWPF限定だから気をつけた方がいいよ
UWPやSilverlightでは.NETオブジェクトはアンマネージドなXAML DOMのラッパー
だからC#でツリー組むよりXAMLをテキストで読ませたほうが速かったりする

**デフォルトの名無しさん** · 2017/11/07(火) 09:22:10.77

>>669
そうなの?
じゃ、UWPのxamlとWPFのではかなり別もんなのか

**デフォルトの名無しさん** · 2017/11/07(火) 09:39:39.90

>>669
それじゃUWPのobjフォルダに有る　xxx.g.csファイルって一体何だ？

**デフォルトの名無しさん** · 2017/11/07(火) 11:28:45.06

一発目でwpfはツレーだろうな。理解していることの前提要素が多すぎる

**デフォルトの名無しさん** · 2017/11/07(火) 11:42:33.72

MVVMに手を出すとさらにつらくなるね

**デフォルトの名無しさん** · 2017/11/07(火) 12:39:39.96

素直にWinFormsで入門すればよかったのにw
C#に限らず今時のプログラミング言語自体、まったくの初心者にとっては躓きそうな要素が
色々あるのに、xamlがーとかMVVMがーとか言い出したら、地雷原を素足で歩くようなもの

**デフォルトの名無しさん** · 2017/11/07(火) 16:42:34.80

>>674
ConsoleでHello,world からでしょ。

**デフォルトの名無しさん** · 2017/11/07(火) 16:56:18.48

ほんとそれな
Viewの前にModelの作り方、GUIの前にCUIの作り方覚えろと

**デフォルトの名無しさん** · 2017/11/07(火) 17:39:21.94

今時CUIはないでしょう。
モチベーションが続かないし、Windows FormでポトペタでGUI作るより
CUIの方が簡単とも思えない

**デフォルトの名無しさん** · 2017/11/07(火) 18:04:12.00

>Windows FormでポトペタでGUI作るより
いきなりそれからやろうとすると、基礎が身に付かんだろって話なのよ
言語の基本仕様くらい真面目に学習せんかーい

**デフォルトの名無しさん** · 2017/11/07(火) 18:06:52.09

>>678
じゃあ聞くけど、CUIを選択することで学習できる基礎って何？
そんなものはないよ。あるなら言ってみ？

そういう話なら、たぶん構造化プログラミングをすっ飛ばしていきなり
クラスベースのOOPに挑戦する弊害の方が大きいと思う

**デフォルトの名無しさん** · 2017/11/07(火) 18:45:12.03

CUIは入出力がものすごく単純でGUIみたいなフレームワークの知識がほぼいらないので言語の仕組みそのものに学習を集中できる

**デフォルトの名無しさん** · 2017/11/07(火) 19:06:46.18

>>679
MVVMのModelで実行できるプログラムにGUIって必要か?

**デフォルトの名無しさん** · 2017/11/07(火) 19:09:33.93

ぶっちゃけ、GUIやConsoleプログラムのI/Oって泥臭い処理で
プログラムの本質を学ぶ上では必要の無いものなのかもね。

**デフォルトの名無しさん** · 2017/11/07(火) 19:15:19.61

とりえあず、かずき大先生の記事を貼っておく。
日本語のWeb情報でWPFに関してこれを超えるものはないと断言できる。
http://blog.okazuki.jp/entry/2014/12/27/200015

お布施、払いたい人はこれ
https://www.amazon.co.jp/gp/product/B015WXYUUU/ref=oh_aui_d_detailpage_o01_?ie=UTF8&;psc=1

これも必須
https://www.amazon.co.jp/%E3%82%A8%E3%83%83%E3%82%BB%E3%83%B3%E3%82%B7%E3%83%A3%E3%83%ABWPF-Presentation-Foundation-Programmers-SELECTION/dp/4798114200/

**デフォルトの名無しさん** · 2017/11/07(火) 19:33:09.38

>>680
curses全力否定？

**デフォルトの名無しさん** · 2017/11/07(火) 19:38:51.28

>>684
cursesみたいに複雑にしようと思えばいくらでもできるけど、printfとscanfだけでも最低限のものは作れるでしょ
GUIだとその最低限のものを作るのにも書かなきゃいけないことが多くて初心者向きじゃない

**デフォルトの名無しさん** · 2017/11/07(火) 19:41:29.82

ボタン押してラベル書き換えるぐらいもやる気がないなら
プログラムやる資格はないと思う

**デフォルトの名無しさん** · 2017/11/07(火) 20:40:45.13

>>ボタン押してラベル書き換えるぐらい
のことでもViewのコードビハインドにするかViewModelとの相互作用にするかでも悩まされるのがWPF

ViewModelとの相互作用で書いた方が可搬性があがるよ！
…分かるけど、それ、初心者向きかしら？そんなことも思わすのがWPF