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/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

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

>悩まされる
悩まなくね？
ボタンのラベルを他から参照する事が無い、次の画面に持ち越さずその場限りの使い捨てで良いならコードビハインド

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

>GUIだとその最低限のものを作るのにも書かなきゃいけないことが多くて初心者向きじゃない
という程にはWinFormは難解じゃないわな。その辺りは良くも悪くもVisual Basic譲り
ただ、GUIから入るとFormの存在感が強すぎて、ブラックボックス的な部分もあって、クラス
などの基礎知識の理解を遅らせかねない部分があるのは確か
とはいえ、今のご時勢CUIでストイックにプログラミング勉強しようとも人に勧めようとも
思わないけどな
ボール無しでの基礎訓練も大事だけど、やっぱシュート練習のほうが楽しいわさ

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

>>688
>ボタンのラベルを他から参照する事が無い、次の画面に持ち越さずその場限りの使い捨てで良いならコードビハインド
そう。悩まないんだ！すごいねー。それで可搬性のあるコードになるんだー（棒
みんなそうなるといいねー。すてきー（呆

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

低能なら低能でコードビハインド使うのは別に悪ではない。

**デフォルトの名無しさん** · 2017/11/08(水) 00:24:21.64

けっきょく低能よばわりされるんだ、悪じゃないのに。へー（もはや何もなし

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

かずきは大したことないよ。ただブログこまめに発信してるだけ。
neueccみたいな何か作り出せるのが最強

**デフォルトの名無しさん** · 2017/11/08(水) 05:58:24.72

低脳が悪とは限らない
まあケースバイケース

**デフォルトの名無しさん** · 2017/11/08(水) 07:32:05.97

>>693
まともなドキュメント書かなきゃ誰も使ってくれないけどね。
Rubyが流行ったのは早い段階で英語のドキュメントがあったから。

オレ、ドキュメントなんて面倒くさくて書きたくないけどw

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

WPF使えるようになれば分かると思うが、理解できないのはWPFが糞設計だから。
決してPGのスキルの問題ではない。もしPGのスキルのせいにしてる奴がいるとすれば、
そいつはWPFを理解していないだけ。

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

コードビハインドとか新しい用語作っておきつつ学習した後で
それは柔軟性が足りないとか言われても困る

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

>>696
どんな糞でも食せるように調理できるのはスキルではないと言うのか。
オレはスカトロマニアかw

**デフォルトの名無しさん** · 2017/11/08(水) 12:29:17.17

ウメーとこだけバインド利用しましょうでええんや
キッチリカッチリ無理無理。ハゲるぞ

**デフォルトの名無しさん** · 2017/11/09(木) 05:49:47.74

WPFが糞というのはないな、xamlが糞だというのはおおむねそうだな
xmlもどきで記述されたものを専用パーサで読みUIを作るという着想はいいんだ
問題は書式、カッコ増えすぎインデント深すぎ、可読性が悪いし記述がしにくい

**デフォルトの名無しさん** · 2017/11/09(木) 07:52:05.77

フラットだったら可読性が良いってわけでもないと思うがな。
少なくとも、デザイナー使わないと読んでも理解できない.Designer.csよりはマシになったと思う。
xamlでネストが深くなりすぎたと思ったら<UserControl>でモジュール分割するタイミングだな。
main()関数の中に全部の処理を記述するようなことしてるから糞に思えるんだよ。

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

ｘｍｌの問題なのは重々承知だが、コメントの書き方何とかならんものだろうか

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

>>700
xmlモドキじゃなくxmlだろ。
独自構文だともう少しスッキリはするかも。

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

なんとかバインドの雰囲気がわかったと思ったらコマンドってなんだよ
これ1番わからねぇわ

**デフォルトの名無しさん** · 2017/11/10(金) 17:50:48.32

WPFの本質が見えているとなぜ普及しなかいなんて一目瞭然なんだが、
それをPGのスキルのせいにするのは基本的にWPFの本質、使い方が何も分かってないのだろう。

**デフォルトの名無しさん** · 2017/11/10(金) 18:37:03.92

WPF以外でスタイリッシュなUIって作れるのありますか？
WinFormじゃメチャクチャ工数がかかるのでWPF以外で何かいいのあったら教えて頂きたいです。

**デフォルトの名無しさん** · 2017/11/10(金) 18:40:08.93

UWPがあるぞ

**デフォルトの名無しさん** · 2017/11/10(金) 18:59:21.06

>>706
今だとElectronの一強

**デフォルトの名無しさん** · 2017/11/10(金) 18:59:42.16

wpf難しい…
データバインドがうまくいかない
データベースから取ってきたリスト型のデータをコンボボックスのitemsourceに設定するだけなのにうまくいかぬ

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

Electronは初見なので調べてみます。

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

>>705
>それをPGのスキルのせいにするのは
PGのスキルのせいだと思うぞ。
MSが日本の平均的スキル(日本のITは奴隷産業なので世界の底辺以下のそのまた以下の以下のゴミクズ以下)を超えた物を作ってしまったのでついて行けてないだけ。

**デフォルトの名無しさん** · 2017/11/10(金) 19:46:17.42

WPF開発は個別の画面の前に全体の仕組みの設計から入らないと上手くいかないというかクソ手間かかるんだよな
日本人はそういうの苦手でボトムアップが好きだから根本的に合わないんだよ

**デフォルトの名無しさん** · 2017/11/10(金) 20:39:39.13

まぁ確かに、Formsだとポトペタで画面作ってダブルクリックで開いたイベントハンドラに
ちょいちょいとコードを書けばそれで動くものができたからな。そのお手軽さは素晴らしい。

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

WPFでも全く同じ事出来るんですが…

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

ｈｔｍｌの手書きが出来るならxamlなんて言うほど大変じゃないんだけどな
swingのレイアウトよりは遥かにマシだと思うし