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

このスレへの固定リンク： http://5chb.net/r/tech/1428631142/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1 ：デフォルトの名無しさん：2015/04/10(金) 10:59:02.30 ID:GFQ4+Eaw: ユーザーインターフェイスシステム、Windows Presentation Frameworkについて語るスレ。

Visual Studio 2013 & 2012 & 2010
http://www.microsoft.com/visualstudio/jpn/downloads
Microsoft .NET Framework 4 (Web インストーラー)
http://www.microsoft.com/downloads/details.aspx?familyid=9CFB2D51-5FF4-4491-B0E5-B386F32C0992&displaylang=ja
Microsoft .NET Framework 4 (スタンドアロンインストーラー)
http://www.microsoft.com/downloads/details.aspx?familyid=0A391ABD-25C1-4FC0-919F-B21F31AB88B7&displaylang=ja
Microsoft .NET Framework 4.5
http://msdn.microsoft.com/ja-jp/library/vstudio/5a4x27ek.aspx

前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
http://peace.2ch.net/test/read.cgi/tech/1410523389/

関連スレ
Microsoft Silverlight その9
http://toro.2ch.net/test/read.cgi/tech/1321150267/

Windowsストアアプリ開発について語れ part2
http://peace.2ch.net/test/read.cgi/tech/1388921236/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/
2 ：デフォルトの名無しさん：2015/04/11(土) 03:42:48.16 ID:2NJz6esb: 2ゲット
3 ：デフォルトの名無しさん：2015/04/11(土) 12:02:46.46 ID:6QBeTfwQ: 　～　終　了　～
　
4 ：デフォルトの名無しさん：2015/04/11(土) 14:11:57.96 ID:CY7VALwp: 今年はWindows 10とVisual Studio 2015が出るけど、WPFへの移行は進むのかな。

Windows 10が業務タブレットで利用できるようになれば、日本のタブレット向け業務アプリ開発は、
ブラウザベースから、WPFかWindows Formsの割合が増えると思う。

何をどうやったところで、ネイティブアプリの方が、起動も動作も入力作業も圧倒的に速いから。
5 ：デフォルトの名無しさん：2015/04/11(土) 18:12:08.64 ID:WRrZF/9s: ああ、そうだな。
そんな未来が来るといいな。

今のMSに期待できるものがあるか？
俺は
6 ：デフォルトの名無しさん：2015/04/12(日) 20:51:47.46 ID:oPP3J4XZ: PrismのTriggerActionをつかってListBoxのScrollToTopを実行しようと思ったんですが
TriggerActionにListBoxのインスタンスを送るために、依存関係プロバティーで飛ばそうと思ったんだが
<prism:XXXTrigerAction ListBox={Binding ....｝　/>と書くときのListBoxの指定方法がわかりません
Binding ElementName=だけだとNullになるようで、どうしたら良いのか教えて下さい
7 ：デフォルトの名無しさん：2015/04/15(水) 12:23:54.07 ID:mNjG8RUL: 質問です。
pList As New ObservableCollection(Of cItem)
こんな感じで独自クラスのコレクションを宣言して
DataGrid.ItemsSource = pList としています。

AddするとDataGridにも反映されるので便利なのですが、
このグリッドにDBから検索した結果を表示させると、
1行追加毎にイベントが発生して遅くなるのでは、と思い、
DB読み込みの前にイベントの発生を止め、
読み込み後に再度イベントを発生させれば改善されるのでは、と考えました。

このイベント発生停止/再開って可能でしょうか？
8 ：デフォルトの名無しさん：2015/04/15(水) 13:48:43.76 ID:NbC8SVHD: まず第一に、遅くなるのでは？と思っただけで改善に着手する君の頭を改善する
あとはObservableCollectioを継承してOnPropertyChangedとOnCollectionChangedを止めたらいいんでね
9 ：デフォルトの名無しさん：2015/04/15(水) 13:50:42.82 ID:NbC8SVHD: wpf suspend databindingでググったらそんな回答ばかりでした
10 ：デフォルトの名無しさん：2015/04/15(水) 14:06:57.11 ID:Unri1ETs: ObservableCollectionをちょいといじってイベントを投げないAddRangeを自前で作る。
デフォでAddRangeが無いのは、そーうゆ事なんだろうと。
11 ：デフォルトの名無しさん：2015/04/15(水) 16:13:30.34 ID:mNjG8RUL: なるほど、ありがとうございました
手抜きできるかなーと思いながら質問してみたんで、
まっとうな方法で試してみます
12 ：デフォルトの名無しさん：2015/04/17(金) 22:07:07.72 ID:O2siDKC3: 多分ものすごく頑張っても、その視点では大して速度変わらんと思うよ
仮想化しているから表示している行の分しかイベント処理しないし
13 ：デフォルトの名無しさん：2015/04/19(日) 18:54:04.47 ID:hQHj8N+6: これ難しすぎないすか？

1行目の9列目がパースエラーになってて
でもどこが悪いのかわかんねーから
同じxamlファイル名で作り直してもまだ同じとこでパースエラー。
空ファイルなのに？信じらんねー
14 ：デフォルトの名無しさん：2015/04/19(日) 19:07:21.63 ID:dhzBOV6W: プロジェクトだかソリューションのクリーンを試してみて
たぶんキャッシュに反応してるんだろ
15 ：デフォルトの名無しさん：2015/04/19(日) 20:08:39.29 ID:vTGSIxF9: >>13
適当に編集 (空の行増やすでもなんでもいい) して保存、元に戻して再度保存したらなぜか動くかも。
16 ：デフォルトの名無しさん：2015/04/22(水) 18:27:48.82 ID:IbzWzzJQ: wpfでおすすめの参考書
か解説サイトってある？
ちなみにwpf入門でググルと上位に出てくる
@itの解説だとよく分からないぐらいのレベルです
17 ：デフォルトの名無しさん：2015/04/22(水) 21:10:28.57 ID:I8D63Rzc: 残念ですが、オワコンなのでありません
終わったって言うと、始まってすらいないなどとツッコミが入るところとか、特に終わってますね
18 ：デフォルトの名無しさん：2015/04/25(土) 08:29:58.52 ID:2KWb5y7Z: てか、@ITの解説ってホント何も知らない初心者向けだし、
俺も最初はそこから始めた
あれでわからないってのがわからない
19 ：デフォルトの名無しさん：2015/04/27(月) 18:59:40.74 ID:ZgJFLRhp: @ITは確かにレベルを低めに狙っているけど
@ITだったら初心者が分かるはずというのは言い過ぎだ
20 ：デフォルトの名無しさん：2015/04/28(火) 20:36:49.63 ID:tCrEOFJC: public enum DataType { AAA, BBB, CCC, }
public class ViewModel
{
public DataType SelectedType { get; set; } // 実際は変更通知プロパティ
}

XAML
<ComboBox SelectedItem="{Binding SelectedType}">
　<vm:DataType>AAA</vm:DataType>
　<vm:DataType>BBB</vm:DataType>
　<vm:DataType>CCC</vm:DataType>
</ComboBox>

これでenum値を選択できるのですが、このままではenum値をToString()した文字列が表示されます。
ComboBoxにはenum値に対応した別の文字列を表示させ、SelectedTypeにはenum値が入る、というようにしたいです。
どういう方法がありますか？
21 ：20：2015/04/28(火) 20:38:45.25 ID:tCrEOFJC: ちょっと補足ですが、View側のみで何とかしたいです。
22 ：デフォルトの名無しさん：2015/04/28(火) 21:12:37.73 ID:4ktewRHX: ValueConverterはViewだって誰かが主張していたような
23 ：デフォルトの名無しさん：2015/04/28(火) 21:27:09.69 ID:pDdBB2WM: 早い話、XAMLだけでは無理だから
デザイナーにValueConverterだけは書いてと頼む
それがWPF
24 ：デフォルトの名無しさん：2015/04/29(水) 00:50:53.14 ID:J4ivSUNz: VC#2010 WPF .NET4.0ClientProfileで組んでいます。

NagigationWindowを使って３枚のPageを遷移する
ものを作っています。
Page1に設置しているButtonをクリックするとPage2へ、
Page2に設置しているButtonをクリックするとPage3へ、という動作です。

ここで、Page1 --> Page2　や Page2 --> Page3 において
Buttonクリックからページ遷移まで時間がかかることがあります。
（100%時間がかかるのではなく、４割くらいの確率です。かかるときは5秒ほどかかります。）

これを何とか抑止したいのですが方法はありませんでしょうか？
NavigationWindow生成時にPage1～3のインスタンスを予め作る、
ということが出来れば良いのかなと思いましたが
ググっても見つかりませんでした。
宜しくお願いします。
25 ：デフォルトの名無しさん：2015/04/29(水) 03:11:00.93 ID:EM1eDUtO: >>20

Viewのみでって言ってるけどenumは定義していいんだよね。
だったらenum値と表示したいstringの2プロパティを持ったクラスは作っていいのか?
作っていいならそれのコレクションをプロパティとして作れば、後はXAMLだけ。
多分こんな感じ。

<ComboBox
ItemsSource="{Binding VMのクラスのコレクション}"
DisplayMemberPath="表示したい文字列プロパティ名"
SelectedValuePath="セットしたいEnum値のプロパティ名"
SelectedValue="{Binding 選択したEnum値を受け取るVMのプロパティ}"/>
26 ：20：2015/04/29(水) 09:25:00.03 ID:PDjNGZso: <ComboBox SelectedItem="{Binding SelectedType}">
　　<ComboBox.ItemTemplate>
　　　<DataTemplate>
　　　　<TextBlock Text="{Binding Converter={StaticResource myConverter}}" />
　　　</DataTemplate>
　　</ComboBox.ItemTemplate>
　<vm:DataType>AAA</vm:DataType>
　<vm:DataType>BBB</vm:DataType>
　<vm:DataType>CCC</vm:DataType>
</ComboBox>

としました。
Converterを適用するためにItemTemplate設定したけど、この方法でいいのかな？
(ItemContainerStyleの方でもやってみたけど、プルダウンの項目にしか適用されなかった)
ありがとうございました。
27 ：デフォルトの名無しさん：2015/04/30(木) 12:08:29.73 ID:1Sbv8r4s: スレの上の方見てるとXAMLってオワコンで未来がないの？
HTMLに近い書き方でGUI作れるって聞いたから勉強してみようと思ったんだけど
28 ：デフォルトの名無しさん：2015/04/30(木) 13:41:49.14 ID:QA2QlJvl: 未来があるって抽象的だな
何がどうなっていれば未来があると言えるんだ？

VisualStudioCodeではElectronを採用したらしいから
(http://blog.shibayan.jp/entry/20150430/1430328999)
WPFのクロスプラットフォーム化はされないと思うぜ
WPFをクロスプラットフォーム化できるなら
VisualStudio自体をクロスプラットフォーム化するだろうしな
29 ：デフォルトの名無しさん：2015/04/30(木) 14:20:01.41 ID:QA2QlJvl: ・Windowsで動作すればいい
・今後機能の追加や改善が見込めなくてもいい
・多少気が利かないところがあっても広い心で許せる

くらいなら使えるんじゃね
俺も使ってるけどFormsよりはマシよ
30 ：デフォルトの名無しさん：2015/04/30(木) 15:20:04.92 ID:1Sbv8r4s: 自分用のアプリしか作らないのでFormより良ければ十分です
勉強してみる、ありがとう
31 ：デフォルトの名無しさん：2015/04/30(木) 20:15:25.33 ID:V42NsGzx: Build2015見たけど…

WPFは終わってる

ここからは巻き返しがない
さよならだね！
32 ：デフォルトの名無しさん：2015/04/30(木) 20:42:05.20 ID:z7JbgbHO: どこにだ？
すでにお前には逃げ場などない！
このMSの罠に掛かったのだ！
33 ：デフォルトの名無しさん：2015/05/01(金) 11:22:01.45 ID:vilMfTm7: >>26
enumにattributeでmarkup拡張
34 ：デフォルトの名無しさん：2015/05/06(水) 23:51:00.34 ID:xSx5EStZ: https://twitter.com/ufcpp/status/595858432177078272

office16プレビュー使ってみたけど
操作感が今まで通りでまずびっくりして、
buildの資料見てみたらUIだけXAML化して
95%くらいのコードはwin32版のをそのままとか書いてて
またびっくりした。
35 ：デフォルトの名無しさん：2015/05/07(木) 12:24:11.43 ID:Cq4kbyXI: MS的にはXAMLを使っていこうっていう気はあるのね一応
36 ：デフォルトの名無しさん：2015/05/07(木) 15:14:25.34 ID:+yI4RSPE: 嬉しいお知らせですね
37 ：デフォルトの名無しさん：2015/05/07(木) 16:50:56.97 ID:zhtzqZS2: XAML=WPFなの？
38 ：デフォルトの名無しさん：2015/05/07(木) 18:26:42.86 ID:KZqJgOca: >>37
XAMLはSilverlight(オワコン)、WPF、StoreApp、Universal App(Windows 10)で使われる
39 ：デフォルトの名無しさん：2015/05/07(木) 19:19:46.85 ID:HCFKQ/v1: Universal appが普及することに期待して
今後は業務アプリ作製に練習兼ねてWPF使おうと思う
が、これまでwindows formsしか使ってないから敷居が高いな
慣れればformsと同じような早さで作れるようになるのか？
40 ：デフォルトの名無しさん：2015/05/07(木) 21:14:18.38 ID:fQls54Ru: >>34
Windows10専用じゃないだろうが、そうするとC# - C++/CLI - nativeC++の3階層でゴリゴリやってんのかな。
そのへん楽できるフレームワークができてるなら公開してほしいものだが。
41 ：デフォルトの名無しさん：2015/05/07(木) 23:46:22.89 ID:UqF45q9L: 今更そんなややこしいことするか？
C++/CXで作ってるってだけじゃないの
42 ：デフォルトの名無しさん：2015/05/08(金) 00:12:25.16 ID:v8DvF7BX: C++/CXってストアアプリ専用じゃないのか？WinRTなしで使えるんだっけ？
43 ：デフォルトの名無しさん：2015/05/08(金) 00:37:27.83 ID:rtQrrRIy: 開発者特権で何か抜け道があるという流れ
44 ：デフォルトの名無しさん：2015/05/08(金) 08:07:20.64 ID:v8DvF7BX: おそらくそういうのがあるだろうから使わせろって話だろ>>40
45 ：デフォルトの名無しさん：2015/05/08(金) 23:57:45.25 ID:6cZOl+Us: XAMLじゃなくてHTMLで書けたら良いのになー

ASP.NET MVCかじりながら
WPFも覚えないといけないとか、
時間がかかり過ぎる。
46 ：デフォルトの名無しさん：2015/05/09(土) 00:00:38.15 ID:yC22YGmq: >>39
自分は、WPFのDataGridが重すぎて、
Formに回帰した。

WPFは、MSが半分放棄してるような気がする。
Silverlightは完全に放棄されたしね。
47 ：デフォルトの名無しさん：2015/05/09(土) 00:21:38.43 ID:5NEoo1tP: DataGridは重いし機能面でも微妙
それでも後から追加されたコントロールなんだよね
.NET4まではあれすら標準には存在しなかったんだぜ
WPF Toolkitに含まれたのも2.0のSPが出たころでさ
最初はListView.ViewにGridView設定してやるくらいしかなくて
これがまた…
48 ：デフォルトの名無しさん：2015/05/09(土) 00:28:42.75 ID:5NEoo1tP: 補足しておくと.WPFとNET3.0が世に出たのは2006/11
WPF ToolkitにDataGridが含まれたのが2008/08
49 ：デフォルトの名無しさん：2015/05/09(土) 11:22:27.85 ID:YfK4icTM: >WPFにおいても安定性やパフォーマンスの向上が図られた

Microsoft、「.NET Framework 4.6」のリリース候補版を公開
http://www.forest.impress.co.jp/docs/news/20150508_700968.html?ref=rss
50 ：デフォルトの名無しさん：2015/05/09(土) 13:24:31.36 ID:XjeDHuSP: >>34
XAML化にもいろいろあるからなあ

多分binding使わないでゴリゴリ書いたんだろうな
51 ：デフォルトの名無しさん：2015/05/09(土) 14:31:39.01 ID:diwpp2uS: >>46
Universal appsならともかくWPF自体には既になんらメリットないもんな
マイクロソフトもやる気なくてchartコンポーネントの開発停止しちゃってたりして酷い
52 ：デフォルトの名無しさん：2015/05/09(土) 15:55:39.19 ID:c0c55jKA: WPFの普及に失敗したってのはよくわかるんだけど、結局Windowsアプリの主流は今もWindowsformsってことなの？
53 ：デフォルトの名無しさん：2015/05/09(土) 16:08:09.33 ID:jPvozQIh: パフォーマンスさえ何とかしてくれたら他の欠点は我慢してWPF使うんだけど
54 ：デフォルトの名無しさん：2015/05/09(土) 18:06:57.09 ID:RlZf2Nj4: 何をもって主流というのかにもよるが数なら今でもWin32ネイティブが一番多いと思う
55 ：デフォルトの名無しさん：2015/05/09(土) 18:33:34.60 ID:LB9k92JE: WPFを切るなら切るでデスクトップアプリ用のUIフレームワークを
ネイティブでも.NETでも良いから新調しやがれってなもんだがの

Build 2015で既存のデスクトップアプリをClassicなんて呼び始めやがったから望みは薄そうだ…
56 ：デフォルトの名無しさん：2015/05/09(土) 19:03:06.03 ID:5NEoo1tP: ストア政策失敗によるアプリ不足で
緊急輸入に踏み切ろうとしてるとは思えない言い草ｗ
57 ：デフォルトの名無しさん：2015/05/09(土) 19:36:46.35 ID:ESnKcuW3: そういえばedgeとかいう次期ブラウザはmetro専用なのか？
期待してるがそれなら使い手がなさそう
タブレットならまだしもパソコン上ではデスクトップで使えないとどうしようもないぞ
58 ：デフォルトの名無しさん：2015/05/10(日) 00:46:02.37 ID:WRstRn4o: DesignModeでフォーカスの判定どうやるか知ってる方いませんか？
MS謹製のFlyout等はデザイナで要素選択時だけ表示されますが、カスタムコントロールではどうやっても出来ない・・・orz
59 ：デフォルトの名無しさん：2015/05/12(火) 17:27:50.86 ID:Ss0NJSwd: >>57
＞そういえばedgeとかいう次期ブラウザはmetro専用なのか？

yes
ただしWin10はストアアプリもウインドウ表示できるから
デスクトップでも使える
60 ：デフォルトの名無しさん：2015/05/12(火) 17:32:04.55 ID:rl9WPQXU: っていうかWin8.xのIEと同じく、ストアアプリみたいに振舞うネイティブアプリなんじゃないの？
61 ：デフォルトの名無しさん：2015/05/12(火) 17:38:11.03 ID:rl9WPQXU: っていうかストアアプリの押し売りは本当もう結構。
Win8.1をデスクトップで使ってるとこれが鬱陶しくてしょうがない。
62 ：デフォルトの名無しさん：2015/05/12(火) 18:56:53.28 ID:xIaJ+ReW: 富士通ねえ
まだあんな無駄なものの研究開発を続ける気力があったか
63 ：デフォルトの名無しさん：2015/05/12(火) 19:36:28.81 ID:v6k+5NTN: >>59
それじゃストアアプリ頑張る意味ないじゃない…(´・ω・｀)
64 ：デフォルトの名無しさん：2015/05/13(水) 20:57:23.87 ID:ca5UJOx9: >>60

http://blogs.msdn.com/b/visualstudio_jpn/archive/2015/03/02/a-first-look-at-the-windows-10-universal-app-platform.aspx
＞「Project Spartan」ブラウザーはそれ自体が Windows ユニバーサルアプリであり、
＞Windows ストアを使用して更新されることで、常に最新の状態が維持されます。
65 ：デフォルトの名無しさん：2015/05/14(木) 19:50:02.95 ID:f6tNHcRS: windowsのレイアウトXMLが全く普及しないと思ったら
採用してるのAndroidとwindowsだけなんだな
iOSアプリは基本的にUIにXMLは使わない方向
コードも増えまくってメリット少ないことが明らかになってきている
66 ：デフォルトの名無しさん：2015/05/14(木) 20:06:41.13 ID:ctue3ow3: 根本的に野暮ったいんですよ
いい加減に悟りなさい
67 ：デフォルトの名無しさん：2015/05/14(木) 20:38:55.89 ID:3/EeSSqc: json

ｗｈｙ～　japanese　people!!!
68 ：デフォルトの名無しさん：2015/05/14(木) 22:55:27.59 ID:yGHIVAbH: 正直ウィンドウ化出来るんならどっちも変わらないような気がす
69 ：デフォルトの名無しさん：2015/05/14(木) 23:11:42.66 ID:e6Gq7kS/: でもフォームデザイナのわけのわからん挙動より、書いたことしてくれるだけのザムルの方が、慣れたら使いやすい気がします
70 ：デフォルトの名無しさん：2015/05/14(木) 23:48:10.71 ID:3/EeSSqc: >>68
ユニバーサルアプリは

ドラッグアンドドロップできない
標準ダイアログない
メニューない
タブない
ツリーない
プロセス間通信ない
通常の常駐ない
71 ：デフォルトの名無しさん：2015/05/14(木) 23:55:38.09 ID:EvTZfzw1: デバイスをオープンしたりもできないよね。

今度はユニバーサルアプリなんて名前になったのかw
ジャンクロードバンダムかよw
72 ：デフォルトの名無しさん：2015/05/15(金) 00:17:27.74 ID:g46xazLt: Spartanで試したら確かにドロップできなかった
まさかHTML5のドラッグドロップAPIもサポートしないつもりか？

他は別にいいけどドラッグアンドドロップなしでデスクトップアプリの代替は無理だよ
73 ：デフォルトの名無しさん：2015/05/15(金) 08:22:49.49 ID:aOglazS+: >>65
Qｔってのがあってな
74 ：デフォルトの名無しさん：2015/05/15(金) 19:27:30.05 ID:ibL5CPfe: formsプログラマが今から学習するなら
普及する可能性0のWPFより
HTML5とjavascriptやる方がよっぽど良いよね
75 ：デフォルトの名無しさん：2015/05/15(金) 19:52:55.82 ID:TJvHiIRG: >>74
ザ…xamlはこれからだから…！
76 ：デフォルトの名無しさん：2015/05/15(金) 21:25:48.68 ID:JpYXjSx5: HTML5でGUI書くのってってストアアプリじゃないWin7のデスクトップアプリでもできるの？
77 ：デフォルトの名無しさん：2015/05/16(土) 11:43:16.76 ID:07dlJcDh: >>76
HTML Applications
https://msdn.microsoft.com/en-us/library/ms536496(v=vs.85).aspx
78 ：デフォルトの名無しさん：2015/05/16(土) 16:24:01.09 ID:eLDY5yJ3: >>77
ありがとう
79 ：デフォルトの名無しさん：2015/05/17(日) 14:09:11.64 ID:8g4YNRzt: ListBoxのContextMenuを動的に動かすのがめんどいので、試しにVMでContextMenuのインスタンスを生成してListBoxにバインドしたら動いた
何となく問題ありそうなんだが大丈夫なんだろうか？
80 ：デフォルトの名無しさん：2015/05/17(日) 14:30:37.79 ID:Mih3hbe2: WPFの質問です。
Windowの横に別のWindowを新規で表示したいのですが、
そういった位置の指定はどうすれば可能でしょうか？

新しく開くWindowのOwnerに設定して中心に表示する、
といったことはプロパティの設定で簡単にできますが、
上記のやりたいことはウィンドウの位置をピクセルで取得して
自分で計算してピクセル指定、しか方法ありませんでしょうか？
81 ：80：2015/05/17(日) 14:31:57.00 ID:Mih3hbe2: 具体的には下記のようにしたいです。
ウィンドウの上辺は同じで、真横にぴったりくっつけて表示したいです。
■が元のWindow
□が新規のWindow

■■■■■■□□□
■■■■■■□□□
■■■■■■□□□
■■■■■■
■■■■■■

宜しくお願いします。
82 ：80：2015/05/18(月) 02:15:31.59 ID:5NHUNu/I: Window#Top
Window#Left
Window#Width
でそれっぽいこと出来ました。
83 ：デフォルトの名無しさん：2015/05/18(月) 12:22:54.63 ID:VMddewbE: 仕事の忙しさにかまけて今までWindows.Forms使っていたんですが
そろそろWPFを使ってみようかと思っています。

先ずは勉強がてらに名簿管理アプリでも作ってみて感触をつかんでみようと思いますが
画面に取得した値をセットしたり、入力後の値を登録する為に取得したりする辺りの部分で
WPFで調べてみるとよく使われているのが INotifyPropertyChanged+PropertyChanged みたいな感じだったのですが
Windows.Formsの時は基本的に融通が効きにくかった為、バインドを使用しないで原始的な方法で記述していました。
（入力チェックなどは登録前に一括で処理していました。）

WPFでは基本的な方法としては皆さん INotifyPropertyChanged+PropertyChanged を使っているのでしょうか？
先行されている皆様のご意見をいただければと思います。
84 ：デフォルトの名無しさん：2015/05/18(月) 13:18:27.40 ID:Z6GfAvhk: 不便だと思いつつ使ってるわ
85 ：デフォルトの名無しさん：2015/05/18(月) 13:23:35.32 ID:Os+SE7uo: >>83
DataRowをbindすれば、Propertyなんちゃらは不要
86 ：デフォルトの名無しさん：2015/05/18(月) 13:49:00.91 ID:VMddewbE: >>84-85
レスありがとうございます。
いずれの方法にせよバインド方式の方が多い感じなんでしょうか・・・。
となると入力時にValidation使って制限かけるとかその辺になるのかなと想像します。
ご意見ありがとうございました。
87 ：デフォルトの名無しさん：2015/05/18(月) 15:27:15.46 ID:KEATmqs+: XAMLをいじるの楽しい
88 ：デフォルトの名無しさん：2015/05/18(月) 16:10:47.32 ID:7XDwggG0: 奇特なお方だねそりゃ
89 ：デフォルトの名無しさん：2015/05/18(月) 19:44:32.48 ID:+nCvwBZH: >>87
ちょっとわかる
90 ：デフォルトの名無しさん：2015/05/18(月) 19:54:33.98 ID:92QLSF+E: 次第にだれる
91 ：デフォルトの名無しさん：2015/05/18(月) 20:36:40.60 ID:1sJj6qeI: >>65
　iOSのレイアウトファイルであるxibの実態はXMLだけど、まず読まない（読めないな）な。その分ツールの使い勝手をよくしている。
XAMLは知らんけど、イクリスプ時代のAndroidのツールはクソだ。
92 ：デフォルトの名無しさん：2015/05/18(月) 21:27:47.00 ID:xUq2iLoH: Android Studioとかいう奴、今は使い物になるようになったんだw
出た当時は散々だったような
93 ：デフォルトの名無しさん：2015/05/18(月) 21:40:40.98 ID:1sJj6qeI: Android Studioは触ってないからなしらんが、イクリスプ時代のは間違いない
クソだ。
94 ：デフォルトの名無しさん：2015/05/18(月) 21:52:39.04 ID:xUq2iLoH: >>93
なんだそういうことかw
95 ：デフォルトの名無しさん：2015/05/19(火) 11:45:02.91 ID:MIJnA7rY: GridSplitterで、質問です。
うまく伝わるかちょっと心配ですが。
Rowを5分割（0,1,2,3,4）、Columnを3分割（0,1,2）。
GridSplitterをColumnは1に全域でSpan5で分割。Rowは1,2にそれぞれSpan1で分割。

実現したい、動作としては。左右のSplitterが上下に自由に動かしたい。
今は、右を上に持っていこうとしても、左のSplitterの位置に制限される。

はたして、これは、Splitterでどうにかできるのか？別のコントロール使うのか？
こうすればいいという方法があればお願いします。
96 ：デフォルトの名無しさん：2015/05/19(火) 12:35:12.94 ID:MIJnA7rY: 自己解決しました。
やっぱりGridの入れ子をすればよかったんだ！
ずっと<Grid.ColumnDefinitions>の中で<Grid>を入れ子にしようとエラーでした。
97 ：デフォルトの名無しさん：2015/05/19(火) 20:59:02.95 ID:ZBCVKuxh: ？？？
98 ：デフォルトの名無しさん：2015/05/20(水) 01:11:36.95 ID:tT1xTrvt: なんでＷＰＦはよさげな参考書がないんだ
唯一よさげなのは絶版でアホみたいな値段で売ってるし
99 ：デフォルトの名無しさん：2015/05/20(水) 01:34:01.84 ID:ymV6jbme: 洋書はいっぱい出てるしググればただでe-Book版が落とs（
100 ：デフォルトの名無しさん：2015/05/29(金) 08:18:17.60 ID:mNu9yEsT: wpfカスタムコントロールライブラリを作るとThemes/Generic.xamlを自動的に見に行ってくれますが
普通のクラスライブラリで同じことをするには何処を変更すればいいのでしょうか
101 ：デフォルトの名無しさん：2015/05/31(日) 12:19:12.90 ID:X5IaJJ+r: WPFがわかってきた。Formsとの違いを考えてきたけど
Webアプリだと思って作るといいことがわかった。
これはいいものだ。
102 ：デフォルトの名無しさん：2015/05/31(日) 13:03:23.97 ID:SL+nIhLI: WPFって慣れるとFormで作るより早いよね
103 ：デフォルトの名無しさん：2015/05/31(日) 13:35:35.59 ID:PpoU4VIJ: とっとと、Blend統合したら良いのにな。
Behaviorなんかは標準機能で良いだろ。
104 ：デフォルトの名無しさん：2015/06/12(金) 00:55:48.44 ID:qBpXFxOz: Blend使えば、コントロール配置して
プロパティでテーマ選んだら
あっちゅうまに男前なUIできるのかなと思ったら
そうでもなかった
105 ：デフォルトの名無しさん：2015/06/12(金) 20:46:33.10 ID:wc5hEgZP: WPFの理解なくしてBlendの理解なし
だからBlend使っても何の学習効果もない
106 ：デフォルトの名無しさん：2015/06/16(火) 05:05:24.78 ID:h70AvFfH: てかBlendは訳わからん
普通に手書きでXAML書いた方が100倍楽だわ
107 ：デフォルトの名無しさん：2015/06/18(木) 13:02:34.05 ID:IoJ/1Arx: なんかReactiveUIが褒められてるのをよく見た気がしたので触ってみてるけど
いまいち何が凄いのか理解できないなぁ。イベントの合成とか局所的には
面白そうとは思いつつあまり用途が思いつかなかったりして。
単なるフレームワークとしては目立って悪いところは見つからなかったけど
逆に革新的な感じもしないし、まぁ、そんなもんなのかな？
108 ：デフォルトの名無しさん：2015/06/21(日) 11:42:20.79 ID:YrOnk+Hm: ウィンドウのWidthプロパティにデスクトップのサイズより
大きな値を設定してもデスクトップのサイズになってしまうのですが
デスクトップのサイズ以上のウインドウを作ることはできないのでしょうか？
109 ：デフォルトの名無しさん：2015/06/21(日) 18:03:46.55 ID:PyO8xSB7: WPFとは関係なくデスクトップのサイズで制限されててできないよ。
110 ：デフォルトの名無しさん：2015/06/21(日) 18:49:23.71 ID:YrOnk+Hm: >>109
そうでしたか。ありがとうございます。
111 ：デフォルトの名無しさん：2015/06/21(日) 18:59:11.59 ID:0g6EdVmv: 確かに画面端にはみ出る位置にウインドウを持っていって
反対側をドラッグで広げていくと途中で止まるな

知らなかった
この制約は何の役に立つんだ？
112 ：デフォルトの名無しさん：2015/06/21(日) 19:22:21.08 ID:4ZIe2rYJ: まあ、ウィンドウのY座標はマイナスにできないから、
というのは理由としてあるのかもしれない
113 ：デフォルトの名無しさん：2015/06/21(日) 20:40:56.52 ID:YrOnk+Hm: >>112
ウィンドウのメニューから移動をすればマイナスにできると思います。
114 ：デフォルトの名無しさん：2015/06/21(日) 21:29:10.82 ID:oLbVnuVY: >>113
できないでしょ。
alt + spaceでやってみた？
115 ：デフォルトの名無しさん：2015/06/21(日) 21:36:33.84 ID:oHn44sS9: マルチディスプレイならマイナスの座標は現れると思うが。
116 ：デフォルトの名無しさん：2015/06/21(日) 22:02:29.45 ID:mTVvjbYS: できるな
LONGの範囲なら移動でるだろな
117 ：デフォルトの名無しさん：2015/06/24(水) 02:44:07.33 ID:xLI1RJT3: 仮想化オンのListBoxにObservableCollectionをバインディングしているんですが、
アイテムを下に追加していくと数が増えるに連れてCPU負荷が増大していきます。
アイテムを一番上に挿入していくと常に一定のCPU負荷です。
レイアウト計算の問題だと思いますが対応策はありますか？
118 ：デフォルトの名無しさん：2015/06/24(水) 02:47:12.39 ID:xLI1RJT3: 書き忘れましたが、追加されるたびに一番下にオートスクロールするようにしています。
119 ：デフォルトの名無しさん：2015/06/24(水) 23:01:41.33 ID:yzm4TwW6: どんな方法でスクロールしてるのか知らんが、ScrollIntoViewでやってみたら?
120 ：117：2015/06/28(日) 05:51:30.43 ID:bpwb3R21: >>119
ObservableCollectionのAddイベントを監視してScrollViewerのScrollToEnd（）を走らせています。
ScrollIntoViewも試してみましたが、ScrollToEndのほうが軽い感じでした。

UIの仮想化をするとアイテム数が数千・万単位になるとボトム付近でのスクロールパフォーマンスが悪化するようでしたので、
CollectionViewSourceを利用し、スクロールポジションがボトムにあるときは最後尾付近のアイテムだけを表示して、一番上までスクロールされるとすべてのアイテムを表示するようにして解決しました。
121 ：デフォルトの名無しさん：2015/06/28(日) 08:17:11.05 ID:0jIFNkRO: なんかそれおかしくね？

仮想化されてるのにレイアウト計算するの？
データ持ってくるコードがおかしいとかじゃないのかな
122 ：デフォルトの名無しさん：2015/07/02(木) 19:11:25.54 ID:Sxo/wYyE: 今更Reactive ExtensionやReactive Propertyに手をだしたけど
これ自己満足の世界なのかいな
面白いけど周りがついてこなそうだわ・・・
123 ：デフォルトの名無しさん：2015/07/02(木) 19:26:07.12 ID:dleR9sps: もはや非同期プログラミングのパラダイムに
言語仕様が追いついていなかった時代の遺物としか思わない

javascriptのpromiseとかアホみたいにもてはやされてたけど
asyncの前には単なる化粧したブスに過ぎない
124 ：デフォルトの名無しさん：2015/07/02(木) 19:34:02.05 ID:FDoiVviQ: promise＝ライブラリで実現できる限界
async/await＝言語仕様で真面目に対応したらこうなった
125 ：デフォルトの名無しさん：2015/07/03(金) 23:11:46.03 ID:s08bDnZ6: PreventFocusの処理を差し替えたいのだけどUIelementから継承するしか手段がないのかな？
126 ：デフォルトの名無しさん：2015/07/05(日) 18:53:51.79 ID:zPA17ttg: http://blogs.windows.com/msedgedev/2015/07/02/moving-to-html5-premium-media/

言うのがおせえ
いまさらsilverlightで新規案件なんかねえだろうけど
127 ：デフォルトの名無しさん：2015/07/05(日) 19:42:32.65 ID:aneIwXTm: >>126
遅いもなにも、その記事次のブラウザでサポートしないって言ってるだけじゃん。
Silverlightそのものの死亡宣告はもう何年も前に出てたでしょ
128 ：デフォルトの名無しさん：2015/07/05(日) 21:58:14.09 ID:w3MUvKZE: <TextBox IsEnabled="False" Text="hogehoge"/>
とIsEnabledをFalseにしても、マウス右クリックすると
再変換候補が表示されてそれを選択すると
入力内容が書き換えられてしまうって常識？
バグっぽい気がするんだけど。
129 ：デフォルトの名無しさん：2015/07/05(日) 23:38:06.17 ID:d4YpHmSa: >>128
仕様なんじゃ！？
130 ：デフォルトの名無しさん：2015/07/05(日) 23:46:29.52 ID:X+1MiY1N: UIElement.IsEnabled Property
Gets or sets a value indicating whether this element is enabled in the user interface

どう読んでもバグです。
131 ：デフォルトの名無しさん：2015/07/05(日) 23:47:55.55 ID:d4YpHmSa: そっか…(´・ω・｀)
132 ：デフォルトの名無しさん：2015/07/06(月) 02:16:15.66 ID:Jmnz4zzD: 10年近く経過してるのにしょうもねえ品質だ
133 ：デフォルトの名無しさん：2015/07/06(月) 18:46:36.62 ID:mt5d2gf+: みんな気づいてるとは思うが既にモバイルアプリでもXAML+C#はレガシーサポートの位置付けだよ
HTML,CSS,Javascript（Typescript）がマイクロソフトの推し進める次期主力アプリ開発環境
標準技術じゃないXAMLはどんどん肩身が狭くなる
134 ：デフォルトの名無しさん：2015/07/06(月) 18:51:06.16 ID:1uuV02SE: わかったわかったw
135 ：デフォルトの名無しさん：2015/07/06(月) 20:26:45.99 ID:5s2fPCSH: アプリが一つも登場する事なく死亡してしまうのか
ふびん過ぎる
136 ：デフォルトの名無しさん：2015/07/06(月) 20:28:25.44 ID:Jmnz4zzD: みんな気づいてると思うが既にWPは
137 ：デフォルトの名無しさん：2015/07/06(月) 20:50:46.92 ID:3AiQSNoA: どうせフォームに戻るんじゃないの？
138 ：デフォルトの名無しさん：2015/07/06(月) 22:06:07.34 ID:obPDxtqR: HTMLなんて論外だけど、WPFはとにかく筋が悪すぎた。
139 ：デフォルトの名無しさん：2015/07/07(火) 08:28:49.25 ID:4dnNMkKJ: Binding使いこなせないとそういう感想になるよな
140 ：デフォルトの名無しさん：2015/07/07(火) 09:56:49.17 ID:PjK/lpsq: これからHighDPI時代になるんだからフォームには戻らないんじゃ
141 ：デフォルトの名無しさん：2015/07/07(火) 10:04:16.25 ID:Ge7MDcMZ: どの辺が筋悪いのか挙げていこうぜ
個人的には

・Viewを仮想化している場合の制限がundocumentedすぎ
・FlowDocument貧弱
・少し画面が複雑になると、Blendで問題なく描画できるのに
　VSで描画できないケースが多発する
142 ：デフォルトの名無しさん：2015/07/08(水) 15:13:47.79 ID:Kq4/uUm/: コーディングしている奴のデザイン感覚が悪すぎるのがはやらない一番の原因だな
143 ：デフォルトの名無しさん：2015/07/08(水) 15:42:19.08 ID:Fjn1PRGp: html論外でwpfも駄目ならform一択ということですか？
なにでwindowsアプリ作成したらいいんでしょう。
144 ：デフォルトの名無しさん：2015/07/08(水) 18:20:27.29 ID:5itimQXb: >>143
VB6
145 ：デフォルトの名無しさん：2015/07/08(水) 18:40:24.24 ID:rW6o/Qq/: VB6! VB6! VB6! (V8風に)
146 ：デフォルトの名無しさん：2015/07/08(水) 19:22:29.95 ID:tAjW2x/N: せっかくだからユニバーサルアプリで。
147 ：デフォルトの名無しさん：2015/07/08(水) 19:43:15.62 ID:K3Unqfxi: ユニバーサルアプリ(実質PCのみ)
148 ：デフォルトの名無しさん：2015/07/08(水) 19:49:38.68 ID:Fjn1PRGp: 7でもそれなりに動くんですか？
149 ：デフォルトの名無しさん：2015/07/08(水) 20:43:27.35 ID:WOzgYlaU: ユニバーサルアプはHTMLとWPFの2択だよ
150 ：デフォルトの名無しさん：2015/07/11(土) 01:54:33.35 ID:UVo6H91m: 本屋でストアアプリ調べたらwin7では使えないとか、、、さらに、社内ツールとかでちょこっと使いたい場合、なんかインストールとかしなきゃいけないみたいで色々めんどそうだなぁ。
wpfがよさそうかなぁ、、、
何を初めに勉強しようかまじ悩む。
151 ：デフォルトの名無しさん：2015/07/11(土) 03:32:21.67 ID:lkGf9qTZ: 今更WPFの勉強は要らんだろ
流行る可能性0のWPFよりは1％の可能性にかけてストアアプリやる方がマシ
152 ：デフォルトの名無しさん：2015/07/11(土) 09:57:32.18 ID:KKmeAvvi: なんか社内での今後の開発をＷＰＦに移行するような動き
あるんだけど
実際ＷＰＦの将来性ってどんなものなのかな
153 ：デフォルトの名無しさん：2015/07/11(土) 10:17:00.12 ID:uKki+Yew: そろそろ世に出て10年ですよ
そんでこの状態
お察し
154 ：デフォルトの名無しさん：2015/07/11(土) 12:06:22.94 ID:UVo6H91m: 7で動かないストアアプリをやる気にならない。
10がシェアの中心になるなら考えるけどなぁ
155 ：デフォルトの名無しさん：2015/07/11(土) 12:15:15.44 ID:JMjYdLec: WPFの知識は将来役に立つでしょう
156 ：デフォルトの名無しさん：2015/07/12(日) 11:24:25.17 ID:2Bu9soOt: フォームアプリケーション→WPFの移植作業をするにあたって、
MVVMフレームワークでおすすめってありますか？
どれも一長一短っぽくて迷っています……

MVVM Light toolkit
Prism
Caliburn
Livet
157 ：デフォルトの名無しさん：2015/07/12(日) 11:32:20.10 ID:+HVDChTi: Prism以外ねーだろ
残りは比較に値しない
158 ：デフォルトの名無しさん：2015/07/12(日) 11:54:07.40 ID:NFHy/IHl: WPFの筋は悪くないと思うけどな。完成度が低い部分は所々あるけど。
フォームの方が過去のしがらみ引き摺ってて筋はずっと悪いと思う。
159 ：デフォルトの名無しさん：2015/07/12(日) 12:37:48.81 ID:+HVDChTi: 褒め言葉としては魅力に欠ける
160 ：デフォルトの名無しさん：2015/07/12(日) 13:03:51.40 ID:CmM+wixD: >>156
VMなんてイラネ。
素直にコードビハイドにイベントハンドラ書いた方が後で見て100倍分かりやすいよ。
161 ：デフォルトの名無しさん：2015/07/12(日) 13:28:58.01 ID:nws8O2Q+: ＷＰＦ勉強する場合おすすめの参考書って何？
162 ：デフォルトの名無しさん：2015/07/12(日) 13:57:20.10 ID:+HVDChTi: 古代ではEssentialWPFと言われていた、が
163 ：デフォルトの名無しさん：2015/07/12(日) 18:51:06.20 ID:lnmS7JaY: マイクロソフトはスマソ事業を大幅に縮小する
http://www.gizmodo.jp/sp/2015/07/post_17604.html

WPFどころかストアアプリにも未来はない
windowsは凋落の一途
164 ：デフォルトの名無しさん：2015/07/12(日) 19:19:09.68 ID:nwenW4Ex: スマソマンの誕生であった
165 ：デフォルトの名無しさん：2015/07/12(日) 20:05:59.21 ID:hAS8tPRT: スマホ事業縮小してｽﾏｿ
166 ：デフォルトの名無しさん：2015/07/12(日) 20:52:06.69 ID:UJONfWBn: あ？
167 ：デフォルトの名無しさん：2015/07/13(月) 13:34:22.22 ID:A8Ot3jfM: スマソよりもっと便利なものを作って売ればいいんだよ簡単だよMSがんばれ
168 ：デフォルトの名無しさん：2015/07/13(月) 15:01:55.90 ID:omcT9BDN: javaのListViewのように
1. 独自のViewが使えて
2. 必要最小限のViewだけで使い回す
機能ってありますか？
169 ：デフォルトの名無しさん：2015/07/13(月) 15:18:20.10 ID:HlNV4jRz: 仮想化を有効にしたItemsControlが該当するかな
使ってて不愉快だけど
170 ：デフォルトの名無しさん：2015/07/13(月) 16:03:58.47 ID:nQ4+KrdI: javaにListViewなんかあったっけ？
171 ：デフォルトの名無しさん：2015/07/13(月) 16:47:36.65 ID:HpIVkHbQ: Androidの奴かな～と勝手に予想した
反省はしない
172 ：デフォルトの名無しさん：2015/07/13(月) 18:29:14.28 ID:omcT9BDN: >>169-171
サンクスです！
そう、Androidの奴でした
173 ：デフォルトの名無しさん：2015/07/14(火) 19:58:34.63 ID:8+u+zVS8: C＃使ってxamlとforms使わないで
html5でGUIプログラミングする方法って無いんですかね
174 ：デフォルトの名無しさん：2015/07/14(火) 21:18:31.35 ID:JpKf/pnS: ない
175 ：デフォルトの名無しさん：2015/07/15(水) 00:27:57.51 ID:KI5mj/c8: ｱｷﾗﾒﾛﾝ
もしくはお前作れよ
まともな出来ならgithubで★100は堅い
176 ：デフォルトの名無しさん：2015/07/15(水) 18:31:17.35 ID:h0CQBjQf: bindingはこけると思われてたんだろうな

そうじゃなければc#で簡単にbindingできる仕組みができてたと思う
177 ：デフォルトの名無しさん：2015/07/15(水) 20:46:42.55 ID:eOTgYWNa: AS
178 ：デフォルトの名無しさん：2015/07/15(水) 22:25:49.84 ID:h1c8ZwEG: windowフォームのbindingと
wpfのbindingってどこが違うの？
179 ：デフォルトの名無しさん：2015/07/16(木) 19:15:53.49 ID:36Lkika8: 時々思い出したようにITmediaでWPF入門読むが
毎回添付プロパティの辺りでげんなりしてブラウザーを閉じてしまう
かれこれ5年くらい
仕事でWPF使わないから趣味でしかないんだが
分かりやすい解説サイトとか無いもんか
180 ：デフォルトの名無しさん：2015/07/16(木) 19:18:52.23 ID:W5fbMMsv: どうやっても分かりづらいんだからしょうがないw

だいたい、コードスニペット使わなきゃ誰も空でプロパティ一つ定義できない（する気にもなれない）
ようなフレームワークなんて筋悪すぎ。
181 ：デフォルトの名無しさん：2015/07/16(木) 20:03:02.96 ID:JsJrinDm: 引き算を忘れたフレームワークと表現してる人がいて感心したなあ
182 ：デフォルトの名無しさん：2015/07/16(木) 20:40:43.07 ID:SuTjwGaW: 筋が悪いものを作るといかに普及しないかを証明したと言える
XAMLを主力開発環境に置いた事は
ストアアプリのソフトが全く増えず
マイクロソフトが没落した一因でもある
183 ：デフォルトの名無しさん：2015/07/17(金) 09:04:10.74 ID:z+vJtdL2: WinFormだって、ちゃんと使おうとしたらコントローつ作ってオーナードローで描画しないといけないんだが
そこら辺まで手を出していた連中にはXamlがすごく簡単に見えるんだけどな
184 ：デフォルトの名無しさん：2015/07/17(金) 09:26:53.39 ID:Oj/hYPuB: 簡単に見えるけど簡単じゃない詐欺フレームワークだから流行らないのでは
185 ：デフォルトの名無しさん：2015/07/17(金) 14:06:29.92 ID:nLxMLg7K: Form感覚でやると扱いづらいけど、Bindingで使うものだと理解してからは
Formの方が面倒くさいと感じるようになった。
186 ：デフォルトの名無しさん：2015/07/17(金) 18:31:17.02 ID:OPTuB4Ww: Androidと比べるとかなり酷い
WPFはこれ系で一番古い部類の先駆者でもあるから仕方ないかもしれんが
187 ：デフォルトの名無しさん：2015/07/17(金) 18:47:03.13 ID:u1qp5kB2: いやAndroidのあれこそウンコじゃんw
まだWPFの方がましだよ
188 ：デフォルトの名無しさん：2015/07/17(金) 18:48:17.77 ID:shZ/TyQ7: 俺も思った
Androidと比べて酷いとか、何の冗談かと
189 ：デフォルトの名無しさん：2015/07/17(金) 18:55:37.56 ID:baczLy6F: エアプ乙
190 ：デフォルトの名無しさん：2015/07/18(土) 00:06:27.72 ID:XRQK1UE3: canvasにボタンとテキストボックスぺたぺた張るだけならformsと似たような簡単さで作れる
二の足踏む人もそこから入れば抵抗は少ないはず
191 ：デフォルトの名無しさん：2015/07/18(土) 00:24:08.76 ID:v7Qc6pcA: bindingコンバーター面倒くさ過ぎる
こんなのでクラス一個作らせるとかC♯の発想にはない
Javaプログラマが作った仕様だろ?これ
192 ：デフォルトの名無しさん：2015/07/18(土) 02:07:06.23 ID:0pNWBd0C: >>191
こういう問題解決のためにC#にeventが導入されたというのに
ヘルスバーグならそうしただろう
193 ：デフォルトの名無しさん：2015/07/18(土) 18:50:19.31 ID:G36oA9Oz: プログラム組んどいて、自分達じゃねえとか言うんだよな、某業者。
194 ：デフォルトの名無しさん：2015/07/18(土) 19:42:47.18 ID:OGP7IcNL: お、スキャンダラスな話か？
実名挙げてええぞ
195 ：デフォルトの名無しさん：2015/08/01(土) 17:09:56.17 ID:i53ueqfH: converterは確かに面倒だが、ある程度それらのクラスがストックできてプロパティ感覚で使えるようになれば、なんとか。
196 ：デフォルトの名無しさん：2015/08/04(火) 11:03:49.37 ID:6CEliMtQ: でもコンバーターなりで常にbindingソースにはDB等に書き込める形で保持するようになってると
便利なんだよなー
197 ：デフォルトの名無しさん：2015/08/04(火) 11:31:03.72 ID:zfLjlDTB: 誰もそんなこと否定してないだろ
あまりに冗長だからどうにかしろと言ってるだけで
198 ：デフォルトの名無しさん：2015/08/04(火) 12:28:54.33 ID:6kzh63/n: コードスニペットに登録したら一発で出てくるから問題にならないんだが
http://www.tk4.co.jp/product/snippet_editor/
このエディター使えば簡単だし
199 ：デフォルトの名無しさん：2015/08/04(火) 12:55:41.69 ID:4wCZUsr6: 馬鹿は100万回スニペット貼り付けて「凄い！簡単！」って喜んでて、どうぞ
200 ：デフォルトの名無しさん：2015/08/05(水) 06:35:20.76 ID:ntXDv3CD: Windows10でのストアアプリのウィンドウ表示が思いのほかスムーズだし、
WPFはいよいよ終了だな。
201 ：デフォルトの名無しさん：2015/08/05(水) 07:54:57.86 ID:jbr/4MQ2: 終了してもいいよ
こっちに慣れときゃ移行は楽だ
202 ：デフォルトの名無しさん：2015/08/05(水) 12:11:21.67 ID:DeFhlXsM: ストアアプリは制限ありまくりでデスクトップの代替にはならないって
何度言っても分からないお馬鹿さんがいるな
203 ：デフォルトの名無しさん：2015/08/05(水) 14:48:17.13 ID:LVHnAIsI: まだWPFにしがみつこうとしてる
お馬鹿さんがいるのか・・
204 ：デフォルトの名無しさん：2015/08/05(水) 15:33:41.63 ID:jyJWTPOf: ストアで全て解決するとは思えないが
それはWPFを肯定する理由に全くならないのだよ
205 ：デフォルトの名無しさん：2015/08/05(水) 15:50:06.36 ID:RJdcR1HO: お、おう
206 ：デフォルトの名無しさん：2015/08/05(水) 16:19:26.90 ID:mF9W7r6V: WPFが使い物になろうがなるまいが、それはストアアプリがデスプトップの代替にはなりえない
という事実とは何も関係ない。

馬鹿じゃないのか本当。
207 ：デフォルトの名無しさん：2015/08/05(水) 16:24:03.25 ID:nxXw/daG: まあまあ落ち着いて
WPFはゴミ
それでいいじゃないですか
何の問題もないでしょう？
208 ：デフォルトの名無しさん：2015/08/05(水) 16:32:43.86 ID:fz9obC7T: 誰もWPFが糞なのは否定してないだろ。
頭に石膏が詰まった馬鹿がストアガーとか言い出して、
頭に砂が詰まった馬鹿が釣られただけ。
209 ：デフォルトの名無しさん：2015/08/05(水) 17:27:25.15 ID:hmTZgdQ3: オマエらなんでそんなに馬鹿だ馬鹿だ言いたがるんだ
210 ：デフォルトの名無しさん：2015/08/05(水) 21:28:24.22 ID:IW4PflEb: ディスクトップアプリはWinFormなんでしょうか・・・？
211 ：デフォルトの名無しさん：2015/08/05(水) 21:44:36.73 ID:nxXw/daG: デスプトップは知らんな
212 ：デフォルトの名無しさん：2015/08/06(木) 09:54:24.29 ID:R7qM7oIu: いくらデスクトップアプリの大替にならないだとか喚いても
MSはストアアプリで一本化していく方針
213 ：デフォルトの名無しさん：2015/08/06(木) 10:37:10.52 ID:B2QP2Cbg: ちょっと誤字多すぎんよ～
推敲して推敲
慌てて書き込んじゃ駄目だゾ
214 ：デフォルトの名無しさん：2015/08/06(木) 11:21:12.84 ID:ALMt1QVr: 多過ぎるって代替だけだろう
215 ：デフォルトの名無しさん：2015/08/06(木) 14:54:32.70 ID:JeaY9W3t: アプリケーションの動作互換性を重視するマイクロソフトが
そう簡単にサポートやめたりはしないんじゃないかな

いまだにVB6ベースのアプリケーション動作をサポートしているのか…
https://support.microsoft.com/en-us/gp/lifedevtool/ja
216 ：デフォルトの名無しさん：2015/08/06(木) 19:09:19.29 ID:7vapH058: そりゃサポートはされるだろう。
問題はWPFが使い物にならないまま、
改善もされずにレガシーになっていくという事。
217 ：デフォルトの名無しさん：2015/08/06(木) 20:49:05.65 ID:id4gveud: レガシー = 遺産

だから。
218 ：デフォルトの名無しさん：2015/08/06(木) 21:14:39.72 ID:9CjAgF5A: だからなんだよ
219 ：デフォルトの名無しさん：2015/08/06(木) 22:04:32.05 ID:id4gveud: 遺産だと大切に伝えていくみたいなイメージじゃんw
220 ：デフォルトの名無しさん：2015/08/06(木) 22:18:41.99 ID:e8q/GPLi: windosフォームと比べてwpfのいい所って何なの？
221 ：デフォルトの名無しさん：2015/08/06(木) 22:31:01.94 ID:YtIxgi9m: ハードウェアでの高速描画()　や高DPI対応じゃね？
222 ：デフォルトの名無しさん：2015/08/06(木) 23:23:00.10 ID:AH+dTzzi: 未だにレンダリング基盤がD3D9でマルチモニタDPIに標準対応してない
Microsoft謹製GUIフレームワークがあるらしいです！
223 ：デフォルトの名無しさん：2015/08/07(金) 05:58:30.56 ID:30rx/FUa: >>221
windows formも高dpi対応するって話があるが
そうなると完全にオワコンだな
224 ：デフォルトの名無しさん：2015/08/07(金) 06:38:39.39 ID:nvStELZm: windowsには互換性という足かせがあるからなぁ
225 ：デフォルトの名無しさん：2015/08/07(金) 11:22:05.55 ID:nibSxy0k: それはそうとWPFって本当に速いのか？
WPF以前のVS2008と、WPFで書き直したVS2010で、
圧倒的にVS2008の方が軽かったのだが
226 ：デフォルトの名無しさん：2015/08/07(金) 12:34:30.42 ID:Ge1vGbPu: 何百回とやったよその話題
君は1回目かもしれないがな
227 ：デフォルトの名無しさん：2015/08/07(金) 17:35:57.23 ID:SQfm8Gzv: 好きな方使えよ
228 ：デフォルトの名無しさん：2015/08/07(金) 21:21:11.12 ID:OV+LAhYA: windowsフォームのデータバインドの仕方が
よくわからないので教えてください
参考ページでもいいので
229 ：デフォルトの名無しさん：2015/08/08(土) 15:39:56.72 ID:AJgGl0M+: WPFとMVVMを勉強中・・・
慣れれば組みやすいのかもしれませんが、挫折しそう（汗

皆様はフレームワークなど利用されているのですか？
230 ：デフォルトの名無しさん：2015/08/08(土) 16:35:56.13 ID:AWBqCflR: Prism程度だな
フレームワークじゃなくて標準で含まれているべきツールキットだと思うけど！！！！！
231 ：デフォルトの名無しさん：2015/08/08(土) 19:04:06.95 ID:AJgGl0M+: >>230
ありがとうございます。
Prismを勉強してみようと思います。

フォーカス移動の指示はViewModel
フォーカス移動そのものの処理はViewでよろしいでしょうか？

ViewとViewModelの切り分けが難しいです・・・
232 ：デフォルトの名無しさん：2015/08/08(土) 22:57:02.93 ID:BHIhWFiM: もうVの参照持っちゃえよ。誰も怒んねーよ馬鹿馬鹿しいｗ
233 ：デフォルトの名無しさん：2015/08/09(日) 19:22:52.28 ID:LnKgsDUP: さすがにVの参照を持つのはやりすぎではないか
234 ：デフォルトの名無しさん：2015/08/10(月) 23:12:22.79 ID:65tjAOy9: そんなの考慮しない時代の方が幸福度が高かったかもな
235 ：デフォルトの名無しさん：2015/08/11(火) 00:12:35.64 ID:wWyNsVqi: もうWPFやってないけど、MVVMって結局最後まで違和感がぬぐえなかったなあ
236 ：デフォルトの名無しさん：2015/08/11(火) 05:01:00.57 ID:elaltOKu: DataTemplateでわからない事があるので教えてください。

https://msdn.microsoft.com/ja-jp/library/system.windows.controls.datagridtemplatecolumn%28v=vs.110%29.aspx

↑のページの一番最後にあるサンプルを例にしてやりたい事を説明します。

サンプルではDataGridにDataTemplateが１列あり、DateTimeを扱えるようにしてある。
Bindingは DataGridTemplateColumnに記述せず、リソース側のDataTemplateに記述されています。

このサンプルに２列目のDataGridTempleteColumnを追加して、扱うデータは１列目と同様にDateTimeとします。
２列目のCellTemplate, CellEditingTemplateには１列目とは異なるDataTemplateを作成して指定します。
Bindingには２列目用のプロパティを指定します。

とりあえずコレで、２列目を動作させるという事はできます。

しかし実質１列目と２列目の違いはデータを取ってくるプロパティ名が違うだけなのに、
リソース側にBindingが違うだけのDataTemplateを書くことが非常に嫌です。

リソース側にバインドを直接記述せず、DataGridTemplateColumn 側から指定することは出来ないでしょうか？
そうすれば同じデータ型を扱うプロパティがある場合でもリソース側は常に一種類だけ記述すればいいはずです。

よろしくお願いします。
237 ：デフォルトの名無しさん：2015/08/11(火) 07:38:09.78 ID:I9e7/X97: 正しいものが流行るとは限らない
238 ：デフォルトの名無しさん：2015/08/11(火) 11:30:42.22 ID:BUFYbg0n: ContentPresenter を使えばいい。このcontentにバインド。ContentTemplate にｒｙ　な
239 ：236：2015/08/11(火) 14:54:00.01 ID:elaltOKu: >>238
> ContentPresenter を使えばいい。このcontentにバインド。ContentTemplate にｒｙ　な
ありがとう。
調べてみます。
240 ：236：2015/08/11(火) 22:04:46.35 ID:elaltOKu: >>238
> ContentPresenter を使えばいい。このcontentにバインド。ContentTemplate にｒｙ　な
とりあえず調べて実装しようとしたのですが、うまくいかないで詰まりました。

日付データDateTimeをグリッドセルとして表示するためには
上記サンプルにあったDataGridTemplateColumn を使うか
DataGridTextColumn　を使用するかのいずれかだと思います。

DataGridTemplateColumnを使う場合、プロパティにContentがない、かつBindingがないのでこちらだとプレゼンターは使えないですよね？

DataGridTextColumnを使う場合は、BindingがあるがContentはない、しかしCellStyleがあるので
こちらにリソースで定義したスタイルを指定する、という形で問題ないでしょうか？

ただスタイルで指定する場合、どう指定していいかわかりません。
とりあえず↓のようにしました。

<Style x:Key="myDateCellStyle" TargetType="DataGridCell">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="{x:Type DataGridCell}">
<ContentPresenter Content="{TemplateBinding Content}"></ContentPresenter>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
しかしこれだと不完全だというのはわかります。
DataGridCellは実際はTextBlock?それともDataGridCellの子供？であるとか、
ContentPresenterのContentに渡すべき適切なプロパティはどうするべきでしょうか？
また受け渡し側のコントロールであるDataGridTextColumnのセルはTextBlockなので
ButtonなどのようにContentプロパティを持っていないようです。
持っているのであれば受け渡し側のContentブロック内でセットすればいいのはわかるのですが・・
241 ：デフォルトの名無しさん：2015/08/12(水) 05:12:59.65 ID:XGVJku/y: 閉じタグ書かねーぞめんどくせぇ
<DataGridTemplateColumn>
　　<DataGridTemplateColumn.CellTemplate>
　　　　<DataTemplate>
　　　　　　<ContentPresenter />
242 ：236：2015/08/13(木) 05:02:07.13 ID:SRvYemT+: >>241
できました。
ありがとうございました。
243 ：デフォルトの名無しさん：2015/08/19(水) 19:55:37.49 ID:ac5UfI6n: Livet2015はよだせよ
Prismに移行するぞい
244 ：デフォルトの名無しさん：2015/08/20(木) 12:17:22.11 ID:0EitkODV: あんなもんまだ使ってる奴いるんだ
245 ：デフォルトの名無しさん：2015/08/21(金) 00:44:50.47 ID:5A97l51N: 何だよPrismの何が悪いんだよ
246 ：デフォルトの名無しさん：2015/08/21(金) 08:11:48.38 ID:Tu1fJmAa: 標準ライブラリに含まれていないところ
247 ：デフォルトの名無しさん：2015/08/21(金) 21:10:51.27 ID:00RN+eAC: 検索しにくいところが一番悪い
248 ：デフォルトの名無しさん：2015/08/27(木) 23:47:12.67 ID:eBUEsSh7: ダイアログひとつ満足に出せんWPF

え？
出せる？

それはMVVMパターンから外れてないか？
249 ：デフォルトの名無しさん：2015/08/28(金) 01:21:08.20 ID:La0rg2tq: ViewにDialogService加えて出すだけじゃねーの
250 ：デフォルトの名無しさん：2015/08/28(金) 01:22:08.81 ID:GpKL1gBB: デザパタに縛られてるのは一部ユーザの側だけであってwpfとは何の関係もないわけだが
そこを貫くならユーザ側が頑張ってふるまいを厳格化？すべきだろ
251 ：デフォルトの名無しさん：2015/08/28(金) 01:29:37.22 ID:La0rg2tq: デザインパターンで第一の関心にさく時間を生み出した人もいる一方
考える力を失った人もいるのだなあ
252 ：デフォルトの名無しさん：2015/08/28(金) 01:53:38.77 ID:GpKL1gBB: 盲目的に誰かが書いた教科書を神とすること程、非合理的なことはないわな
良い部分は取り入れればいいけど。ここがMVVMスレであるなら正しいけどな
253 ：デフォルトの名無しさん：2015/08/28(金) 02:14:29.52 ID:k07is2fO: 例えば新しいマイクロソフトのブラウザのEdgeは、
ファイルのダウンロード中であっても、
ブラウザのウィンドウを閉じれば、
「確認ダイアログもなく」
プログラムが終了する
何らかの信念かモデルかに基づいて、
そういう仕様になっているのだろうけど、
ユーザからしたらはた迷惑だ
254 ：デフォルトの名無しさん：2015/08/28(金) 08:04:23.51 ID:ls1PRuKg: 開きなおしたらレジュームするなら問題ない
255 ：デフォルトの名無しさん：2015/08/28(金) 08:23:17.19 ID:TGOAoWaI: 確認ダイアログは慣れたら確認しないからなw
だから確認自体不要にする思想なんだろう
256 ：デフォルトの名無しさん：2015/08/29(土) 08:32:53.75 ID:zntvE+PM: >>255
UAC昇格ダイアログに脊髄反射でOKするヤツ多いしw
257 ：デフォルトの名無しさん：2015/08/29(土) 10:49:52.01 ID:gmx5ty9e: サーセンｗｗｗｗｗ
258 ：デフォルトの名無しさん：2015/08/31(月) 00:41:53.35 ID:kdlq8+8E: 確認しないだけなのか設計に問題があって確認できないのか
どっちなんだい？

それが重要だ
259 ：デフォルトの名無しさん：2015/08/31(月) 23:59:47.84 ID:b/3QgrVm: ViewModelクラスがModelクラスのメンバを参照してViewに表示する
それは分かる
でも型が
Model ≠ ViewModel
でしょ

その辺の吸収はどうやるのかな
LINQなのかな
260 ：デフォルトの名無しさん：2015/09/01(火) 01:56:35.94 ID:YHvi69Fd: アクセサ内でごにょるか、一致させてコンバータでVに合わすかじゃね
なにするんかシランがLINQでもなんでも好きにすりゃいい
261 ：デフォルトの名無しさん：2015/09/02(水) 20:07:29.33 ID:uXSYe9kR: ダイアログはトリガーアクション使えばできるけど、やることの割に面倒なんだよな
ビヘイビアと似たようなものだから難しいわけじゃないが
262 ：デフォルトの名無しさん：2015/09/02(水) 20:39:25.99 ID:d7Q3fn/H: 面倒くさい
この一言がWPFの全てを説明する
263 ：デフォルトの名無しさん：2015/09/02(水) 20:54:13.46 ID:AIAHCYFs: 後でコード見直した時に猛烈に分かりづらいも追加
264 ：デフォルトの名無しさん：2015/09/02(水) 20:58:08.73 ID:sOrOAYyo: XAMLはいつになったらcss相当のものを追加するんですか？

html用ではlessも使えるのに
265 ：デフォルトの名無しさん：2015/09/02(水) 21:26:51.23 ID:uXSYe9kR: Styleタグがｃｓｓ相当だろうが
266 ：デフォルトの名無しさん：2015/09/03(木) 00:23:48.83 ID:o/zoOoQe: 見た目はもう少しシンプルにルーズにやりたいよなぁ
267 ：デフォルトの名無しさん：2015/09/03(木) 09:35:22.27 ID:j51sLT8G: オーナードローやるより遙かにましでFormsには戻れない
268 ：デフォルトの名無しさん：2015/09/03(木) 09:51:54.90 ID:NQZSp0fr: ジャスミンの香りのウンコとオレンジの香りのウンコくらいの違い
269 ：デフォルトの名無しさん：2015/09/03(木) 11:23:17.28 ID:F1Xntc50: CanvasにLineとかで線を書いているんだけど
SizeChangedの時にウィンドウ実寸に合わせて再配置（座標の再計算）したいんだけどどうやるん？
ArrengeとかUpdateLayoutとか全く効果なしでした。
LineなどのSharpオブジェクトの配置座標は親CanvasのActualWidthをバインドしてConverter通して計算してます。
270 ：デフォルトの名無しさん：2015/09/03(木) 12:31:10.49 ID:o/zoOoQe: シランけど相対で位置変わらんくて、コンテナに乗ってるなら、
デザイナで上下？左右？に棒付けりゃ勝手に伸びね？
271 ：デフォルトの名無しさん：2015/09/03(木) 12:31:54.66 ID:Mtr7VddV: 間違いまくりでワロタ
272 ：デフォルトの名無しさん：2015/09/03(木) 13:09:20.72 ID:F1Xntc50: >270
相対位置で描けるの？

とりあえずSizeChangedでCanvas.Childrenの中直接いじって再配置の再計算してみた
親のActualWidthが変わっているのになんでPropertyChangedは発生しないんだろう
273 ：デフォルトの名無しさん：2015/09/03(木) 13:16:21.42 ID:o/zoOoQe: あ、のびねーか。試さんでテキトーに言ってるからなｗスターサイズか
まぁ忘れてくれ
274 ：デフォルトの名無しさん：2015/09/03(木) 15:08:42.44 ID:mL5Ru5VB: ViewBox使って変形させたほうが早くね？
275 ：デフォルトの名無しさん：2015/09/08(火) 22:19:16.25 ID:KktH2j0l: Commandプロパティを持たないコントロール（例えばLabel）をクリックしたらコマンドを呼びたい
でもどう呼べばいいですか
MVVM厳守してとして
276 ：デフォルトの名無しさん：2015/09/08(火) 22:25:52.72 ID:hrJw90JL: 死ねばいい
現実に適応できない生物は死ぬしかないだろ？
だから遠慮なく死んでいい
277 ：デフォルトの名無しさん：2015/09/08(火) 22:44:23.40 ID:XiTHgORh: クリックに反応してCommandを実行するBehaviorでもつければ？
馬鹿らしいけど
278 ：デフォルトの名無しさん：2015/09/09(水) 01:27:36.28 ID:/kgwc7rV: ググればテンプレート使った例とかすぐ出てくるのにな
原理主義の奴は発狂するかもしれないけどこう言うのは
WPFっつーかXAMLっつーかの面白いところだと俺は
思うんだけどな～
279 ：デフォルトの名無しさん：2015/09/09(水) 01:28:03.47 ID:4BbEGdUp: windowformの方がわかりやすいし
ソースも明瞭になってよくね
280 ：デフォルトの名無しさん：2015/09/09(水) 02:21:52.68 ID:aWrddTNo: >>279
別に慣れてるものを使えば良いんじゃね？

俺はお願いされてももうWinFormsの仕事は受けないけどね
自社のプログラムは全部WPFでリライトして殲滅済みだしw
281 ：デフォルトの名無しさん：2015/09/09(水) 11:30:40.90 ID:zdICZVU4: >>275
ButtonのContentをLabelにするだけでいいんじゃねぇの?
282 ：デフォルトの名無しさん：2015/09/09(水) 11:49:40.04 ID:kfehcr7u: >>281
優勝者
283 ：デフォルトの名無しさん：2015/09/09(水) 22:43:30.31 ID:nFBSTt9b: ボタンとして振る舞っちゃうからダメでしょ！
284 ：デフォルトの名無しさん：2015/09/09(水) 22:55:45.27 ID:YYbGMKin: ラベルと同じ見た目のTemplateにして
フォーカス持たなければ中身がボタンでも区別付かないでしょう。
285 ：デフォルトの名無しさん：2015/09/09(水) 23:20:38.66 ID:/kgwc7rV: 面倒臭いからカスタムコントロール作っちゃえよ
ラベル程度ならすぐ作れるさ

もとの質問がラベルに限定していない訳だけど
元々解が無い話なんだからアプローチ変えるしか
無い訳で、それで納得でき無いならずっと唸って
いればいいと思う
286 ：デフォルトの名無しさん：2015/09/10(木) 00:13:18.49 ID:p1BODeP7: InvokeCommandActionを使えばいいんでないの？
287 ：デフォルトの名無しさん：2015/09/10(木) 00:16:23.57 ID:OdK7pfyp: あーEventTriggerからのInvokeCommandActionか
今度こそ正解か？
288 ：デフォルトの名無しさん：2015/09/10(木) 00:58:45.34 ID:GVmKEhgU: イベントが無いからこういう質問してるんだろうに・・・
289 ：デフォルトの名無しさん：2015/09/10(木) 02:51:12.86 ID:vfS4GpFW: やっぱWPFってウンコですね
流行らないものには流行らないだけの理由がありますわ
Silverlightと一緒に荼毘に付した方が良かったのでは
290 ：デフォルトの名無しさん：2015/09/10(木) 02:55:10.60 ID:BaudFOLU: 実際の話MSはWPFどうするつもりなんだろうか
推しつづけるのかなかったことにするか別の新しいGUIを出すのか
291 ：デフォルトの名無しさん：2015/09/10(木) 07:14:34.52 ID:xXpEqfj1: さすがにもう流行ることは無いだろうから
別のGUI出すでしょ
292 ：デフォルトの名無しさん：2015/09/10(木) 09:11:32.03 ID:m6JycITK: もうこの流れ飽きた。散々回答出てるのに叩きたい
だけじゃん。考え方を変えられない奴は何使っても
使いこなせないだろうな。
ここまで粘着質な方がゾッとするわな。
リアルでは関わりたくないわ。
293 ：デフォルトの名無しさん：2015/09/10(木) 09:26:58.17 ID:D/fPtDIR: ストアアプリ、そしてユニバーサルアプリと
技術はそのまま継承されて続いているのに
見えないふりか本当に見えてないんだろうな。
その辺受け付けないならWebアプリでも書くか
何時までもVB6, WinFormsにしがみついていれば
良いんじゃないの。こういうのを良いも
悪いも飲み込んで面白いと思えずに文句しか
言わないなら適正無いから別の道を
進むことをお勧めするよ。
294 ：デフォルトの名無しさん：2015/09/10(木) 10:18:30.91 ID:KjSlFa9J: ストアもユニバーサルもこけてる現状で何言ってんだか
何のためにAndroidアプリやiOSアプリの開発者に必死こいて便宜をはかったと思ってんだ
見向きもされてねえからだよ
295 ：デフォルトの名無しさん：2015/09/10(木) 10:25:58.35 ID:OdK7pfyp: 飽きたんなら目でも瞑ってるかゲームでもしてればいいんじゃない。
お前がこの話を聞くのは一万回目かもしれないけど、相手もそうとは限らんさ。
296 ：デフォルトの名無しさん：2015/09/10(木) 10:50:47.59 ID:M5NMSlSm: OOPなんて今は常識だけど90年代前半までは叩かれまくりだった。

じゃあWPFやXAMLも同じように単に現状では利点が理解されてないだけかと言うと、
それは違うと思う。
297 ：デフォルトの名無しさん：2015/09/10(木) 11:06:32.85 ID:m6JycITK: 意味わからん。頭悪すぎだろう。
技術が問題でこけてるとでも言いたいのだろうか？
単にPCアプリに対するニーズ低下と流行り物の
携帯端末の方に技術者が流れた結果でしかない。

そもそも今回の話はキチンと解を提示されてるのに
なかった事にしてだからダメなんだとか意味の
分からん論理展開してWPFを叩いてるだけじゃん。
298 ：デフォルトの名無しさん：2015/09/10(木) 11:49:49.24 ID:xXpEqfj1: WPFでアプリたくさん作っちゃったから
なくなられると困る
299 ：デフォルトの名無しさん：2015/09/10(木) 11:58:42.84 ID:eLoJewCU: また新しいのに慣れればいいのよ
300 ：デフォルトの名無しさん：2015/09/10(木) 12:15:49.55 ID:7RLiqCwl: >>293
＞何時までもVB6, WinFormsにしがみついていれば
まじこれ
301 ：デフォルトの名無しさん：2015/09/10(木) 12:50:18.97 ID:j8gaTmyT: Vb6は論外として、少なくとも現状ではWPFの方こそ「しがみつく」って表現がしっくりくるな。

俺の仕事ではデータを2Dのグラフにプロットするアプリを作ることが多いけど、
すくなくともこの分野ではWPFはパフォーマンス的に使い物にならないと分かったから
WPFを捨ててWindows Formの方に戻ったよ。
302 ：デフォルトの名無しさん：2015/09/10(木) 13:15:21.55 ID:D9+tm/ol: ラスタ的な処理ならまぁそうだろうなぁ
303 ：デフォルトの名無しさん：2015/09/10(木) 13:27:28.89 ID:xXpEqfj1: WPFのが遅いなんてことあるの？
304 ：デフォルトの名無しさん：2015/09/10(木) 13:41:48.45 ID:Fu33vD4C: ベクターな世界だし色々な画面解像度の事を考慮してるから
オーバーヘッドが大きいから何も考えずに作ると
WPFの方が重くなるけど高速な事を売りにした
グラフコンポーネントとかもあるし要は作り方次第でしょ
描画部分だけじゃなくてデータの扱い方も工夫すりゃ良い

自分で作らず人のコンポーネント使うだけなら
自分にあった物(環境)を選べとしか言えんわな
305 ：デフォルトの名無しさん：2015/09/10(木) 14:35:18.46 ID:6f+ydMmU: ほれ、汎用クリック添付プロバティー
http://ideone.com/Ute70I
<Window
　　　xmlns:hoge="・・・・"
<Label hoge:MouseDownCommand="{Binding foo}" ・・・ />
306 ：デフォルトの名無しさん：2015/09/10(木) 21:42:22.70 ID:cyEEaex4: System.Windows.Forms.TextBox 上で、Alt キー + テンキーの 3 を入力すると例外が発生することがある
http://blogs.msdn.com/b/japan_platform_sdkwindows_sdk_support_team_blog/archive/2015/09/09/system-windows-forms-textbox-alt-3.aspx
307 ：デフォルトの名無しさん：2015/09/12(土) 12:27:58.47 ID:I2NvLH9s: 規定路線としてはWinForm->WPFなんだろう？
WinFormを切るわけにもいかないから（ユーザー側資産が大き過ぎる）
開発保守を最低限にしてVBのランタイムみたいに付け続けるってことに
なってるんだと思うが、ぶっちゃけMSさんはどうしたいんだろうな…
308 ：デフォルトの名無しさん：2015/09/12(土) 17:29:45.30 ID:84hlTrbK: MSさんは
VB6
winforms
html
とあともう一個何かを全部WPFに持っていこうとしたけど流行らなかったのでWPFの開発やめた

これからはUWPとHTML5がMSのメインなんだと思う
309 ：デフォルトの名無しさん：2015/09/12(土) 19:15:14.70 ID:0un12fAk: 開発やめてないぞ、4.6でも新機能と修正はある
恐ろしいのはMFCにすらまだ2015で手を加えていることだが

ただ、MS更新を続けているうちはデスクトップ用のGUIフレームワークを
刷新する気がなさそうだと言うことなんだよなあ
UWPのXaml.UIとかC++/CXやC#で呼び出せるようになってるんだし
あれ正式にデスクトップでも導入できるようにしてまとめてブラシュアップしてけばええのにね
310 ：デフォルトの名無しさん：2015/09/12(土) 21:00:18.29 ID:6CSzORte: できるんじゃないのか？試してないけど
http://dev.activebasic.com/egtra/2015/08/03/823/
311 ：デフォルトの名無しさん：2015/09/13(日) 09:41:33.91 ID:M+tl4tzP: 普通のformアプリは作れるんですがxamlに馴染めないんですがどうしましょう？
312 ：デフォルトの名無しさん：2015/09/13(日) 10:24:26.70 ID:dkMbUACf: WPFの開発は実質終わってる
少しだけ人が残っててできる範囲で修正したり機能追加したりしてる
定年後の余生みたいなもの
313 ：デフォルトの名無しさん：2015/09/13(日) 10:51:37.95 ID:wQ68FTxr: # .NET Framework 4.6 の新機能

## Windows Presentation Foundation (WPF)

* HDPI の強化
* タッチの改善
* 透過的な子ウィンドウのサポート

これを見てどう思うかだな
俺は延命で間違ってないと思う
314 ：デフォルトの名無しさん：2015/09/13(日) 11:06:34.40 ID:oItX2Tp7: 一から覚える場合WinFormsは全く潰しが効かない
WPFのXAMLやMVVMの考え方は今後も知識を生かせる
今後が心配でしょうがない人はJavascriptとHTML5
でも覚えればok

そもそもWPF使ってる人はぶっちゃけWPFその物には
固執してないからなぁ何でそんなに必死にWPF叩いて
WinForms推しする人がいるのか理解に苦しむ

まぁ人の作ったものを組み合わせる事しか出来ない人は
困るのかもしれないけど必要なものは自分で作る
というソフト屋に基本的な事を出来る人なら何でも
良いはずなんだけどな
315 ：デフォルトの名無しさん：2015/09/13(日) 11:10:24.51 ID:wQ68FTxr: >>311
それでもやる
モダンなWebフレームワークなんかは
WinFormsのふるくさいプログラミングモデルよりはWPFに近い
全く役に立たないということはないはず
荒削りと機能不足で一挙手一投足にイライラさせられること以外はね
316 ：デフォルトの名無しさん：2015/09/13(日) 11:28:48.39 ID:dkMbUACf: >>314
絶対逆だと思うけど
winformsはどこでも使える技術

XAMLは局所の技術
317 ：デフォルトの名無しさん：2015/09/13(日) 12:01:38.45 ID:wQ68FTxr: (Windowsなら)どこでもって意味？
318 ：デフォルトの名無しさん：2015/09/13(日) 12:22:49.19 ID:eCHhBYVR: WinFormsは良くも悪くもMFCを焼き直したようなものだしねぇ。
MFCで作ってた人には取っ付きは良いけど、古臭くて面倒臭い部分もそのまま引き継いじゃってる。
今更、新規で覚えるのは微妙。WPFも微妙っちゃ微妙だけど、>>315と同意見。
319 ：デフォルトの名無しさん：2015/09/13(日) 12:41:30.92 ID:YSppvu0P: WinFormsはDelphiを焼き直したようなものだよ
320 ：デフォルトの名無しさん：2015/09/13(日) 15:07:58.12 ID:FlqY3Y7R: WPFとXAMLを叩いてるからってWindows Formを評価してるわけじゃないけど。
321 ：デフォルトの名無しさん：2015/09/13(日) 15:35:05.30 ID:wQ68FTxr: Forms vs WPFみたいな方向に持ってく対立厨いるよね
そんなんじゃなくて、ウンコ味のウンコとカレー味のウンコみたいな関係
322 ：デフォルトの名無しさん：2015/09/13(日) 19:20:10.60 ID:dkMbUACf: winformsがMFC焼き直したって言ってるのはMFC使ってこなかった人だな
Delphiを焼き直したってのが一番近いかな

他でも使えるっているのはjavaとかその他大勢のことだよ
XAMLとMVVMはつぶしが聞かない技術
323 ：デフォルトの名無しさん：2015/09/13(日) 20:59:18.76 ID:To+jAhsd: winformsよりWPF派かな
もちろん適材適所で使い分けていくつもりだけど。
324 ：デフォルトの名無しさん：2015/09/13(日) 21:07:05.76 ID:eCHhBYVR: MFCはVC6から使ってる。
リソースファイルをほとんど使わなくなったのには感動したけど、
他はMFCでDialogプログラム作るのとそんなに変わった気がしない。
Delphiは知らない。
325 ：デフォルトの名無しさん：2015/09/13(日) 22:52:00.35 ID:q3JnkdTU: おいおい知らないなら黙ってれば良かったのに
326 ：デフォルトの名無しさん：2015/09/13(日) 23:26:40.21 ID:JKcg5ntv: >>322
WinFormsとJavaを一括りにできるって凄いセンスだな
それだったら何でも一緒じゃねーの？
もしかしてAWTとかで時が止まってる人？

MVVMがwebアプリの世界でも評価されてるの知らなそうだし
やろうと思えばiOSやAndroidのアプリもかけるのが
WPF, SL -> store -> UWPとMSが駒を進めてる技術ライン
この状況でその意見って単に時間止まってるだけでしょ

VB6, DelphiとWinFormsが同じ感じなのは当然
同じ人が関わっていて思想が一緒だからね
でも今時MVCやMVVMのようにレイヤーを分けない
考え方、実装は古臭いでしょう

MFCが未だにキープされてるのはOfficeの様にC++で
ゴリゴリ書かれたものがまだ残ってるからかな？
Win32とかレガシーなものを捨てたくても資産が多すぎて
捨てさせてもらえないのが現状だし
327 ：デフォルトの名無しさん：2015/09/13(日) 23:59:26.65 ID:wQ68FTxr: 評価はしてないな別に
出来の悪い親だ
328 ：デフォルトの名無しさん：2015/09/14(月) 00:15:15.61 ID:AvIdvwo+: フレームワークのレイヤーがとか言ってるやつはOpenGLがまだ使われてるのを知らないんだろうな
かわいそうに
329 ：デフォルトの名無しさん：2015/09/14(月) 00:18:58.16 ID:AvIdvwo+: それにWin32捨てたらwindowsは何もできなくなるぞｗ
OSの役割が描画だけだと思ったら大間違いだｗｗｗ

Win32捨てると言うことを書く時点でなんもしらないゆとり臭が漂ってくるｗ
330 ：デフォルトの名無しさん：2015/09/14(月) 00:34:36.72 ID:+FKDdk9/: Win32を捨てるとドライバが全部動かなくなるね
解決するためにはWin32に変わるネイティブAPIを提供しなければならないけど
どうせ同じようなものになるのに置き換える意味が無いよな
Win32を捨てるとかっていう発想がまず無いわ
思い浮かばん
331 ：デフォルトの名無しさん：2015/09/14(月) 01:13:00.86 ID:h9CenDqd: >>324
＞他はMFCでDialogプログラム作るのとそんなに変わった気がしない。
物凄く変わっているだろ！どんだけ鈍いんだよ。気付けよ！
332 ：デフォルトの名無しさん：2015/09/14(月) 01:33:02.85 ID:1lK9g7CY: >>329
>>330
うへーWinFXとかWinRTとか知らんの？
前からMSはレガシーなものを捨てたくてあれこれ
やってるのにその流れすら分からんとは

この流れで誰も書いてない描画のこと思い浮かべちゃう
様では狭い知識しかないんだろうなと想像できるけど
ある意味日本のIT土方を象徴する感じではあるな

そもそもwin32だってwin16からの妥協の産物みたいな
もんだぜ？何のために.net framework作ったのかも
理解してなさそうだよな
333 ：デフォルトの名無しさん：2015/09/14(月) 08:05:39.63 ID:P1MtCzUR: >Win32を捨てるとドライバが全部動かなくなるね

なにか違和感があるな。
ドライバはWin32APIに情報を渡してるほうじゃないのけ？
立場が逆というかなんというか。
334 ：デフォルトの名無しさん：2015/09/14(月) 09:11:03.44 ID:Z0K6zfx/: レイヤーの違うところにいる二人が罵り合ってるようにしか見えないね
335 ：デフォルトの名無しさん：2015/09/14(月) 09:21:47.06 ID:tOm8GBtx: 馬鹿と阿呆の争いと捉えれば同じレイヤーじゃありませんか？
336 ：デフォルトの名無しさん：2015/09/14(月) 12:19:33.89 ID:+FKDdk9/: ワロタ
ドライバがWin32APIを使ってないとでも？
337 ：デフォルトの名無しさん：2015/09/14(月) 12:43:46.72 ID:xp8Z5bMG: >>328
この発言全く理解できないんだけどなんで突然OpenGLとか出てきちゃうの？
mvvmのviewは分離してあるからWPFだろうがiOSだろうがAndroidだろうが
共通のモデルやロジックでいけるけどWinFormsはがっちり下のレイヤーと
絡み合ってるからいかにも古臭いという話でしょ？
全然キャッチボールになってないように見えるね
338 ：デフォルトの名無しさん：2015/09/14(月) 12:53:38.71 ID:tOm8GBtx: 同じ阿呆なら踊らにゃ損損

私は遠慮しておきます
339 ：デフォルトの名無しさん：2015/09/14(月) 13:03:16.91 ID:xp8Z5bMG: >>338
我慢できずに書き込んでる時点で仲間だから気にする事ないよ
340 ：デフォルトの名無しさん：2015/09/14(月) 17:27:03.99 ID:AvIdvwo+: WinFX　←これ笑うところ

win32はwindowsの大部分の機能を提供してる部分だから捨てる以前になくなると何もできなくなる
.netだってほとんどwin32の上に乗ってる

winRTだけでいいならそれ使ってください

win32が妥協の産物というならwindowsの存在意義自体妥協の産物だなｗ
341 ：デフォルトの名無しさん：2015/09/14(月) 17:34:34.02 ID:AvIdvwo+: win32API使わないでユーザーが時刻を取得できるのか？
ファイルを操作できるのか？
342 ：デフォルトの名無しさん：2015/09/14(月) 17:41:14.04 ID:LPDpOOOC: 連投するほどアイデンティティが傷ついたらしいぞ
謝罪と賠償をすべきではないか
343 ：デフォルトの名無しさん：2015/09/14(月) 17:46:20.74 ID:AvIdvwo+: しょうもないなw
windowsの機能は大部分がwin32のDLL群で実現されてる
これは動かしようのない事実
344 ：デフォルトの名無しさん：2015/09/14(月) 17:52:45.15 ID:B32AStzW: >>341
レイヤーの違う実装詳細なんか知らなくてもいい
345 ：デフォルトの名無しさん：2015/09/14(月) 17:55:01.39 ID:AvIdvwo+: >>344
君個人はwin32なくしてもいいと思ってんの？
346 ：デフォルトの名無しさん：2015/09/14(月) 18:05:08.57 ID:xp8Z5bMG: おー、発狂したかw
現状の話なんてみんな分かってるの
今後どうなるという話だからMSの思惑の話してるのに
あさっての方向で語り出しちゃってイタイイタイ
リアルでも会話にならんと言われるタイプなんだろうな
347 ：デフォルトの名無しさん：2015/09/14(月) 18:05:15.13 ID:h9CenDqd: >>342
なんかIDかっちょいいな
348 ：デフォルトの名無しさん：2015/09/14(月) 18:13:25.10 ID:B32AStzW: >>345
別にいいよ。
Win32の知識なんて、もう何年も使ってないし。
349 ：デフォルトの名無しさん：2015/09/14(月) 18:28:50.48 ID:Z0K6zfx/: こういうレスの応酬以外にWPFについて語ることはないのかね？
350 ：デフォルトの名無しさん：2015/09/14(月) 18:35:21.63 ID:LPDpOOOC: うーん
面倒くさい以外の感想はないんだよね
351 ：デフォルトの名無しさん：2015/09/14(月) 18:53:05.05 ID:h9CenDqd: 実際の開発現場では
formアプリと
wpfアプリの比率はどれくらい？
352 ：デフォルトの名無しさん：2015/09/14(月) 20:11:35.20 ID:U6a7RUxT: うちはWinFormsは過去の資産の手直しや改造がメイン。
新規はWinFormsでないとダメな理由でもない限りWPFだよ。

他はどうなのかわからん。
353 ：デフォルトの名無しさん：2015/09/14(月) 20:30:15.92 ID:0QbhkudZ: WinFormsのままだよ
だって誰もWPFなんてやろうともしない
存在知ってるのがいるのかも怪しい
俺が趣味でやってるだけ
354 ：デフォルトの名無しさん：2015/09/15(火) 17:23:12.42 ID:iOYYD9/a: 仕事はjavaだけだよ
それかhtml5か

周りでc#で開発してるの聞いたことないよ
業界に入って一個も聞いたことがない
355 ：デフォルトの名無しさん：2015/09/15(火) 18:51:25.42 ID:3JAJExdm: 狭い業界にいるんだな。
知見の無いweb屋なんてそんなもんか？

俺は車載の組み込み屋さんだけどPC用のツールとか
作るときはWPFとか普通に使うぜ。
最近はゲーム開発とかでもc#は必須技能だし
サーバーサイドだってMS系の人はいくらでもいる。
356 ：デフォルトの名無しさん：2015/09/15(火) 19:05:05.98 ID:NamCCdFJ: 確かにウチもJAVAやHTML5の案件も多いけど、WPFも普通に使うね。
357 ：デフォルトの名無しさん：2015/09/15(火) 21:03:38.99 ID:iOYYD9/a: web屋じゃないよ
通常の企業内部のシステムだよ
WPFでやったら他の会社が運用とか改修できないだろうな
WPF何それって言われるだろうからWPFの全部説明して納得してもらうのが一番の問題点だろうな
358 ：デフォルトの名無しさん：2015/09/15(火) 21:11:16.71 ID:iOYYD9/a: 利点が抜けてた

クライアントがいると思ってWPFの利点をどうぞ
↓
359 ：デフォルトの名無しさん：2015/09/15(火) 21:14:53.42 ID:OVPpnewM: Unityでゲーム開発するなら自動的にC#も使うしな
360 ：デフォルトの名無しさん：2015/09/15(火) 21:25:37.65 ID:hgxuynXg: あらあら。必死に話題そらしちゃってw
企業システム屋なんてweb屋とほぼイコールのくくりやん
余計なお世話だけどもっと外の世界を見た方が良いよ
しかしそんな人がなんでこんな場末のスレに来てるんだろ
361 ：デフォルトの名無しさん：2015/09/15(火) 21:28:45.39 ID:iOYYD9/a: 山岡さんなら本当のweb屋を明日連れてくるんだろうな
362 ：デフォルトの名無しさん：2015/09/15(火) 21:34:22.12 ID:P5bYuqhu: IT業界の最底辺って感じｗ
363 ：デフォルトの名無しさん：2015/09/15(火) 21:37:26.35 ID:iOYYD9/a: 底辺？意味がわからないなあ

でも本気で
＞企業システム屋なんてweb屋とほぼイコールのくくりやん
って言ってるのかな～

web屋って変な言い方けどかなり馬鹿にした言い方に近い使われ方をしてるよね
小さい会社が自分のところはweb屋みたいなもんですからとかいうけど
昔からある大手IT関連企業は絶対web屋ですなんて言わない
うちもそうだ
364 ：デフォルトの名無しさん：2015/09/15(火) 21:45:51.28 ID:P5bYuqhu: 俺も最底辺だからそう怒るなｗ
365 ：デフォルトの名無しさん：2015/09/15(火) 21:58:58.91 ID:hgxuynXg: デスマとかブラック自慢してるのって大体その辺じゃね？
小さいweb屋は結構自由にやってるイメージがあるなぁ。
潰れるのも早いけどすぐ別のこと始めてたりするしw
366 ：デフォルトの名無しさん：2015/09/15(火) 22:10:39.66 ID:iOYYD9/a: こっちの世界が狭いって言うけど
>>355の書き込み見てみろよ
よく知らないけど組み込みだったらCとかそのあたりだろ？
車載でWPF使ってますならわかるけど自分の使うツールをWPF使ってるから流行ってる
みたいな意味不明の論拠で話されても困る
そっちの話こそ狭いと思うけどね
367 ：デフォルトの名無しさん：2015/09/15(火) 22:15:11.14 ID:FPLJInGY: 悲哀に満ちたスレ
368 ：デフォルトの名無しさん：2015/09/15(火) 22:32:29.83 ID:RjdEoFPe: こないだ組み込み用のプログラムをC#で組んだよ。
Windows臭さを完全に消したGUIが必要だったからWPFも悪くないと思った。
ある程度のリアルタイム処理が必要だったからGCの制御が厄介だったけど。
369 ：デフォルトの名無しさん：2015/09/15(火) 22:43:57.59 ID:3JAJExdm: 必死でワラタw C#使ってるの見たことも無い言うから
書いただけで誰もWPF流行ってるなんて書いて無いし。

あと車載では俺はOS以下のレイヤー担当する事が
多いからCやASM使う事が多いけど、上のレイヤーは
君の好きなJavaでゴリゴリ作るのが最近の流行りだし
過去には試作だけだけどC#も使って作った事もある。
色々あるってこったな。

あとお前さんが業界に入ってって書いてたから業界って
書いただけで狭いのはお前さん自身の視野だと思うよ。
中途半端なプライド拗らせてる様にも見えるし。
もっと視野を広げたほうが楽しいと思うけどな。
370 ：デフォルトの名無しさん：2015/09/15(火) 22:45:24.50 ID:FPLJInGY: 3行以上は心の贅肉
371 ：デフォルトの名無しさん：2015/09/15(火) 22:48:29.90 ID:hgxuynXg: 脂部分が美味いんじゃないのか？
372 ：デフォルトの名無しさん：2015/09/16(水) 01:34:54.60 ID:1zBVai4a: Webに夢見てる人は俺も井の中の蛙だと思うw
二昔前のJava界隈の人とよく似てる。
373 ：デフォルトの名無しさん：2015/09/16(水) 05:56:51.42 ID:+sWUxIis: 仕事はjavaだけ、周りでもC#使ってるの見たことも無いなら、
なんでこのスレに来て書込みまでしたのかとｗｗ
374 ：デフォルトの名無しさん：2015/09/16(水) 07:57:37.69 ID:gYRc3sT6: 単芝は見栄
375 ：デフォルトの名無しさん：2015/09/17(木) 22:57:08.98 ID:IUk5zYI3: 三重は名古屋の一部です
376 ：デフォルトの名無しさん：2015/09/24(木) 04:24:14.08 ID:qjIwlXFB: StackPanelにボタンを動的に追加したいとなったとき
MVVMのVだけでできるの？
377 ：デフォルトの名無しさん：2015/09/24(木) 08:28:54.21 ID:QTVnOSJ6: このレス以降のMVVMの話題を禁止します
これは初心者がくだらない錯誤に陥るのを防ぐために必要な措置です
378 ：デフォルトの名無しさん：2015/09/24(木) 08:48:59.78 ID:L9oUwmbY: MPNでMVNOの格安スマホに乗り換えたわ
379 ：デフォルトの名無しさん：2015/09/24(木) 09:13:33.99 ID:XLoPykDH: Vだけ云々はBehavior書けば99%可能
個人的な嗜好としては子コントロールに分割する方を好むが
380 ：デフォルトの名無しさん：2015/09/24(木) 09:41:20.41 ID:A1S7kDMm: 動的なボタン追加削除は、StackPanelじゃなくてListBoxのItemにボタンを仕込んだほうが
処理がかなり楽になりますよ
381 ：デフォルトの名無しさん：2015/09/24(木) 16:55:29.19 ID:csvDCNAP: 久しぶりにFormsのソース見たらゴチャゴチャしてるし、外見変えるのも大変。
382 ：デフォルトの名無しさん：2015/09/24(木) 20:10:55.69 ID:uoYKPkX4: 凄くよくわかる
383 ：デフォルトの名無しさん：2015/09/25(金) 03:56:39.38 ID:zFMRn266: >>380
こんな柔軟なことができるのですね
解決しました。ありがとうございます
384 ：デフォルトの名無しさん：2015/09/25(金) 07:42:05.52 ID:OdLQBYES: その程度の知識はあってVだけ云々抜かしてると思ってた
385 ：デフォルトの名無しさん：2015/09/27(日) 07:06:44.52 ID:gAwInljS: すみません、どうしてもわからないので教えて下さい
ListBoxを水平に表示することはできたのですが
3つしか要素がないのに4つ目の細長いボタン？が表示されてしまいます
表示しないようにしたいです

　　private ObservableCollection<Meibo> _shussekibo;
　　public ObservableCollection<Meibo> Shussekibo
　　{
　　　get { return this._shussekibo; }
　　　set
　　　{
　　　　_shussekibo = value;
　　　　this.SetProperty(ref this._shussekibo, value);
　　　}
　　}
　　public MainWindowViewModel()
　　{
　　　Shussekibo = new ObservableCollection<Meibo>
　　　 {
　　　　 new Meibo { Name = "test1", ID = 34 },
　　　　 new Meibo { Name = "test2", ID = 35 },
　　　　 new Meibo { Name = "test3", ID = 36 }
　　　 };
　　}
386 ：デフォルトの名無しさん：2015/09/27(日) 07:39:11.59 ID:Kj9OLILb: MainWindowViewModelのSetPropertyやらは自分で作ってるメソッドでしょ?
その中で末尾に余計な要素加えるとか変なバグ混じってるんじゃないの?
ShussekiboのCountが3か4かを確認するのが先だな
387 ：デフォルトの名無しさん：2015/09/27(日) 08:52:22.68 ID:RYUOLGPE: >>385
もしこれがprism使っているやつだとしたら、この中だと「_shussekibo = value;」は、
次の行の「this.SetProperty(ref this._shussekibo, value);」で同じことをやっているから不要

これが影響しているとも思えんが、この行削除をテストしたらどうでしょうか
388 ：デフォルトの名無しさん：2015/09/27(日) 11:51:18.19 ID:Yw2aNncA: DataGridのCanUserAddRowsがtrueで新規行用の分がListBoxにも表示されてるだけのような？
389 ：デフォルトの名無しさん：2015/09/27(日) 12:57:20.54 ID:gAwInljS: DataGridのCanUserAddRowsがtrueが有効だったため
空の要素が自動で増えたのが原因でした
prismを使用しているので「_shussekibo = value;」も不要でした
助かりました。ありがとうございました。
390 ：デフォルトの名無しさん：2015/10/10(土) 16:46:06.84 ID:T0kGs6ko: ListBoxに動的にボタンを並べているのですが、
commandを使用してどれが押されたかを知る方法がわかりません。イベントハンドラでならわかります。
391 ：デフォルトの名無しさん：2015/10/13(火) 04:11:29.40 ID:XhrZD+F6: リストボックスにデータをbindしているのですが、項目の追加が反映されません。
ボタンを別途設置して、それをクリックしたら listBox.Items.Refresh(); するように書けば反映されるのですが、これをbindで自動的に行うにはどうしたらよいでしょうか。

↓リストボックスのxml。bindTestをバインドしている
<ListBox x:Name="listBox" ItemsSource="{Binding Path=bindTest, Mode=TwoWay}"/>

↓こんなクラスをバインドしています。文字の配列があって、それをbindTestというプロパティに入れている
public class MainWindowDataBind : INotifyPropertyChanged {

public List<String> bindTest {get{return _list;}}
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged(string propertyName) {
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
public void addData(String message) {
_fileList.Add(message);
OnPropertyChanged("bindTest");
}
private List<String> _list=new List<String>();
}

そしてバックグラウンドスレッドでaddData("ほげ");して、リストに追加して欲しいです
392 ：デフォルトの名無しさん：2015/10/13(火) 04:24:05.85 ID:al1tSqu5: >>391
コレクションはObservableCollectionを使おう
393 ：デフォルトの名無しさん：2015/10/13(火) 04:43:17.17 ID:XhrZD+F6: >>392
ありがとうございます。そうなるとObservableCollection.add がUIスレッドである必要があって
結局はイベントの情報をどうにかしてUIスレッドに持っていく事は必要という事ですね
394 ：デフォルトの名無しさん：2015/10/13(火) 05:30:32.08 ID:vR/OXaHd: LivetのDispatcherCollectionとかならその辺自動だが
395 ：デフォルトの名無しさん：2015/10/13(火) 05:32:20.01 ID:al1tSqu5: そのやり方だとバインドされているのはコレクション自体であって
Addで追加したコレクションクラス内部の変数はバインドされないよ

バックグラウンドでList<T>を使って
表示したい場合はObservableCollection<T>に追加すればいいよ
396 ：デフォルトの名無しさん：2015/10/13(火) 05:37:00.70 ID:al1tSqu5: バインドしてるObservableCollectionを非UIスレッドから操作する - SourceChord
http://sourcechord.hatenablog.com/entry/2014/02/02/153725
397 ：デフォルトの名無しさん：2015/10/13(火) 21:00:51.79 ID:BuZ2ejFs: 多分ロックオブジェクト的なものを雑に扱ってるねｗ
398 ：デフォルトの名無しさん：2015/10/20(火) 19:04:50.59 ID:nuiMeyE7: VMをXamlから記述したい場合にVMとモデルのひも付けってどうやって行うんですか？
399 ：デフォルトの名無しさん：2015/10/20(火) 20:06:31.06 ID:URXNkH/9: 0点
400 ：デフォルトの名無しさん：2015/10/20(火) 20:34:50.35 ID:oM+8zZ4h: vmのプロパティにでもmodelつっこんどきゃいいんじゃないのか
401 ：デフォルトの名無しさん：2015/10/20(火) 21:02:10.87 ID:PkYJvx+o: >>400
と、いうことはビューモデルがモデルを生成する形になりますか？
402 ：デフォルトの名無しさん：2015/10/23(金) 07:52:26.33 ID:PzxbOvTm: もちろん
403 ：デフォルトの名無しさん：2015/10/23(金) 08:32:36.18 ID:XGjpZksU: >>402
なるほど、ビューモデルは完全にビューの状態を保持するプロパティのみ持つべきだと勘違いしてました。
モデルのインスタンスを持って、プロパティ変更通知を受けて状態を更新すればいいんですね！
404 ：デフォルトの名無しさん：2015/10/23(金) 12:48:20.10 ID:+RsVjwLX: 正しいやり方か分からんが、俺はモデルの親玉クラスをシングルトンにして、VMが勝手にモデルのインスタンスを拾うように組んでいます
405 ：デフォルトの名無しさん：2015/10/24(土) 01:29:07.60 ID:ntPaM7J3: xmlns:i="http://schemas.microsoft.com//expression/2010/interactivity"
このように記述しても
<i: と入力すると<i:(unknown)と出て
Interactionは(上記)の名前空間に存在しませんと表示されます
Microsoft.Expression.Interactions.dllは最初は参照してなくて
イベントリガーを使いたくて後から追加しましたが
上手く参照されていないようです。

新しくプロジェクトを作って同じようにした場合はちゃんと機能します
新しく作りなおすのは大変なのでできれば原因を突き止めて治したいのですが
何卒よろしくお願いします

Windows10 VS2015com .Net4.6 Prism5
406 ：デフォルトの名無しさん：2015/10/24(土) 01:55:37.74 ID:XdSP3zhB: >>405
// になってるのは転載ミス？
407 ：デフォルトの名無しさん：2015/10/24(土) 02:30:37.76 ID:ntPaM7J3: 転載ミスじゃありませんでした！
何度かコピペし直したりしたのに気づかなかった…
ちゃんと動きました。ありがとうございます！
408 ：デフォルトの名無しさん：2015/10/27(火) 00:52:35.18 ID:CThxpzy/: 結局HTMLでデスクトップアプリ作れる時代なってしまってWPFどうすんだ？
409 ：デフォルトの名無しさん：2015/10/27(火) 01:33:48.73 ID:Ge/PiQGy: んなもん随分前から作れるし今更何言ってんだって話
410 ：デフォルトの名無しさん：2015/10/27(火) 07:25:52.75 ID:ozL4kJmX: 好きなので作れよ
411 ：デフォルトの名無しさん：2015/10/27(火) 10:31:21.63 ID:oZ3zd0d4: 人の心配をするのは100年はえーよ雑魚助野郎
412 ：デフォルトの名無しさん：2015/10/27(火) 11:04:58.42 ID:PvVXktS4: WPFもクロスプラットフォーム化の道を進むなら選択の余地はあるんだけどな
現状はMonoのWindowsFormsの実装が進んでいてそちらを使ってるんだけど
413 ：デフォルトの名無しさん：2015/10/27(火) 11:12:44.76 ID:Zj/nXK80: MonoってWin32API呼び出せるの？
つまりちゃんとWineの上にMonoが実装されている仕組みになってんの？
それともWin32APIの呼び出しは禁止？
414 ：デフォルトの名無しさん：2015/10/27(火) 11:43:01.68 ID:PvVXktS4: クロスプラットフォームなアプリの開発では互換性を考慮してP/Invokeを使った実装はしてないのでわからんけど
Wineで実装されてるAPIについては呼び出せるんじゃないかな
知らんけどね
415 ：デフォルトの名無しさん：2015/10/27(火) 11:46:41.02 ID:Zj/nXK80: 平たく言えばMonoの
Form.Handle
のハンドルは一体何が返ってくるのだろう
Wineで使えるハンドルなのか、それともMono独自のハンドルなのか
416 ：デフォルトの名無しさん：2015/10/27(火) 17:14:38.93 ID:rxP9s5gO: ほかのプラットホームでもWinForms使うとか単なる
マゾでしかないだろう

何のためにUI差し替えられる仕組みなんだっつー話だな
完全にUIまで含めてクロスプラットホームにしようと
すると結局ゆがみが出て歴代の奴らは爆散してるんだし
今のmvvmでiOSもAndroidもWPFもUWAも
作っちゃおうぜ位緩いのは革新的だと思うし今更の
ようにWPF単体叩きしてるのは単に世の流れに
ついていけないオールドタイプなだけ
417 ：デフォルトの名無しさん：2015/10/27(火) 18:43:12.19 ID:LyVSHq6d: はい次の方～
418 ：デフォルトの名無しさん：2015/10/28(水) 00:15:27.18 ID:dODxmMrx: 上の段からの流れでなぜWPFまんせーに至るのか
自分でおかしいと思わないのかな？
419 ：デフォルトの名無しさん：2015/10/28(水) 01:52:24.59 ID:1rwDHYC2: どの書き込みの事さしてるのかマジで分からん
仮想敵憎すぎて常人には見えないものと戦ってる人？
WPFを手放しで褒めちぎってる人なんてここ最近の
書き込みで見た記憶ないんだけどなぁ
しかも今時マンセーて・・・
420 ：デフォルトの名無しさん：2015/10/28(水) 11:31:00.55 ID:lvqGKJHt: >>408
＞結局HTMLでデスクトップアプリ作れる
htmlで作っても動きが遅いだろ
421 ：デフォルトの名無しさん：2015/10/28(水) 12:57:04.94 ID:KzTc+6+y: そもそもMVVMはソフトウェア設計実装モデルであってクロスプラットフォームとはなんら関係性無いし
422 ：デフォルトの名無しさん：2015/10/28(水) 19:53:01.27 ID:IwBra72+: >>420
JavaScriptエンジンが速くなってるので遅くはないよ。
423 ：デフォルトの名無しさん：2015/10/29(木) 19:05:42.89 ID:GzF6GGkt: MS自身もVS CodeでXAMLとおさらばしてるしな
424 ：デフォルトの名無しさん：2015/10/29(木) 23:31:31.70 ID:EfgtGFni: ありゃ単にクロスプラットフォームな実装が必要だからElectronなんじゃろ
425 ：デフォルトの名無しさん：2015/10/30(金) 11:27:15.99 ID:AQQU5PYD: http://blogs.msdn.com/b/wpf/archive/2015/10/29/wpf-in-net-4-6-1.aspx

改善する気はあるけど人的リソースが足りなくて後手後手感
426 ：デフォルトの名無しさん：2015/10/30(金) 12:48:09.27 ID:GDTU3KP4: やるやる詐欺はもういいです
けり殺すぞ
427 ：デフォルトの名無しさん：2015/10/30(金) 20:29:54.83 ID:LtdzDD73: なぜ人手が掛けられてないのかよーく考えてみよう
428 ：デフォルトの名無しさん：2015/11/06(金) 12:57:52.50 ID:yMndejLT: WPFどころかXAML自体に将来性はあるんだろうか・・・
ストアアプリとか大コケ状態で将来は消えるかもしれんし
429 ：デフォルトの名無しさん：2015/11/06(金) 19:10:11.02 ID:aHxdlR6N: んなもん気にしてたらコードなんぞ書けないでしょ
10年そのまま使われるプログラムなんぞ殆ど無いんだから
気にしてもしょうがない
430 ：デフォルトの名無しさん：2015/11/07(土) 12:11:50.58 ID:nNVbKIBm: 将来消えたら何だっていうの?
将来は将来でまた別のもん使えばいいだけの話

逆に新しい技術には手を出せません、覚えられません、
なんて奴らはもともとWPFなんて使えてないだろうし、
このスレ来てるとしてもアンチだけだしね
431 ：デフォルトの名無しさん：2015/11/07(土) 13:05:57.13 ID:qRUcE/WB: 将来どころか現在もないんだから気にならないよね
ストアって何？
432 ：デフォルトの名無しさん：2015/11/07(土) 13:28:15.93 ID:mduBIURz: 将来性の無いもの必死に覚えてどうするんだって話だしな
MS内部の技術者自身もWPFでの開発なんて面倒臭いとか思ってそうだし
433 ：デフォルトの名無しさん：2015/11/07(土) 14:16:27.01 ID:bxbqlbgT: 今Windowsで新しくUI作るならXAMLかDirect2Dで自分で全部書くかぐらいしかないし
WPFでやるよ
434 ：デフォルトの名無しさん：2015/11/07(土) 14:28:02.61 ID:2wvustld: それはどこのWindowsだ？
WPFにしてもXAML使わずにAPI使って普通に書けるわ
435 ：デフォルトの名無しさん：2015/11/07(土) 16:05:32.50 ID:n9vTSPgX: WPFどころか低級APIでバリバリ書けます
436 ：デフォルトの名無しさん：2015/11/07(土) 17:29:33.77 ID:8Yj13GL9: そんな面倒なことするくらいならWPF使うわ
437 ：デフォルトの名無しさん：2015/11/07(土) 17:52:38.22 ID:n9vTSPgX: WPFが売りにしてる機能なんて正直使いどころが無い
WindowsFormsのが手軽で十分すぎ
438 ：デフォルトの名無しさん：2015/11/07(土) 18:42:34.21 ID:6i4+HpQc: ここにきても時間の無駄としか…
439 ：デフォルトの名無しさん：2015/11/07(土) 18:46:55.47 ID:n9vTSPgX: 無駄だからMSもWPFの更新に積極的じゃないわけだ
440 ：デフォルトの名無しさん：2015/11/07(土) 19:46:22.27 ID:AxU/xJtn: WPFはともかくXAMLはやる気満々やろ！
441 ：デフォルトの名無しさん：2015/11/07(土) 20:34:39.29 ID:6hRlMtRG: WPFを理解できない無能の憂さ晴らしか
442 ：デフォルトの名無しさん：2015/11/07(土) 23:21:56.36 ID:s8kK4Wpb: XAMLに将来性無いと言われたらWindows Formsでいいやってなる奴もそらいるわな
俺はWebサイトをデザインする感覚でやれるXAMLは好きだけどな
443 ：デフォルトの名無しさん：2015/11/07(土) 23:41:47.96 ID:RwXev/UR: MSは新しいものを作りすぎ
お金が有り余っているのは分るけどさ
silverlightとかどこいったよ
結局Win32APIが一番安定しているかもね
444 ：デフォルトの名無しさん：2015/11/07(土) 23:50:46.73 ID:qRUcE/WB: Silverlightは糞の役にも立たないから撤退したじゃん
その点WPFはケツ拭く紙くらいにはなりそうだからまだ撤退しない
そういうこった
445 ：デフォルトの名無しさん：2015/11/08(日) 00:04:54.52 ID:/naHGZvp: ストア系もAPIの仕様をコロコロ変えたり迷走してるからな
8用のAPIと10用のAPIは互換性ありませんとか開いた口が塞がらないレベル
446 ：デフォルトの名無しさん：2015/11/08(日) 00:22:38.70 ID:TnPiFwRw: ここ数年でMSが新規に立ち上げて成功したのって.NETくらいだろ
それも2.0でほぼ完成を見たコアな部分だけ
447 ：デフォルトの名無しさん：2015/11/08(日) 02:32:33.92 ID:ZzTQ3fRL: そもそもWinFormsにも将来性なんぞ無いだろ？
結局ちょくちょく書かれてる様に新しいものに
適応出来ない奴らがグダグダ言ってるだけだしな
WPF覚えることで10年無駄にするとかなら考えるけど
簡単なアプリ作るだけなら一月もかからん程度だし
新しいもの出たら新しいのを覚えて使えばいいだけ
それが出来ないなら向いてないからソフト書くのは
やめた方がいい
自分が知らないものを覚えて使って楽しむ感覚が
無い奴も向いてないと思うよ
448 ：デフォルトの名無しさん：2015/11/08(日) 02:41:56.71 ID:TnPiFwRw: WindowsFormsはWin32APIのラッパーでしかないから将来性もくそもない
Windowsが滅ばないかぎりは無くなることはないものだから
449 ：デフォルトの名無しさん：2015/11/08(日) 02:43:56.06 ID:TnPiFwRw: まあ将来的にデスクトップアプリは無くなるとかいう非現実的な前提を付ければ将来性は無いって話にはなるかもな
450 ：デフォルトの名無しさん：2015/11/08(日) 07:09:57.44 ID:MNsoYSk4: WPF使える人はAPIもWinFormsも使えるっしょｗ
451 ：デフォルトの名無しさん：2015/11/08(日) 09:16:53.54 ID:HlEs+VqN: Win32の頃からやってた奴しかWPFには手を出してないということか。
452 ：デフォルトの名無しさん：2015/11/08(日) 10:15:41.55 ID:MNsoYSk4: 自分の都合のいい解釈しかできないのは既に適応力なしの証拠ｗ
必要に応じて勉強すればいいでしょうにｗ
453 ：デフォルトの名無しさん：2015/11/08(日) 10:23:31.35 ID:HD25ztTo: Windows Formが高dpi対応したら普通の業務アプリにWPFは必要ないな。
454 ：デフォルトの名無しさん：2015/11/08(日) 10:24:58.67 ID:MNsoYSk4: そうそう、必要なければここにも来なきゃいい。
455 ：デフォルトの名無しさん：2015/11/08(日) 10:28:17.70 ID:MNsoYSk4: 高dpi対応出来るまで待てるならねｗ
つうか、WPFごとき習得できない人に、高dpi対応もできるんですかね？

>>447氏の言うとおりWPFなんて大して敷居は高くないでしょｗ
456 ：デフォルトの名無しさん：2015/11/08(日) 10:40:02.33 ID:HD25ztTo: >>455
イマドキのWebアプリが作れりゃWPFなんてちょろいもんだな。
457 ：デフォルトの名無しさん：2015/11/08(日) 11:28:49.46 ID:rrYU17zq: Windowsフォームでも高DPIに対応済みだぞ
遅れてるのはお前らじゃないのか
458 ：デフォルトの名無しさん：2015/11/08(日) 11:37:22.12 ID:qE8APb0L: 日曜の昼間からお前らやることないの？
459 ：デフォルトの名無しさん：2015/11/08(日) 12:31:05.55 ID:HD25ztTo: >>457
.NET 4.6 で対応したんかいな?
460 ：デフォルトの名無しさん：2015/11/08(日) 12:43:40.89 ID:+/vDw/dU: マニフェストで高dpiを有効にする
フォームのAutoScaleModeをDpiにする
これで一応は可能っぽいな
461 ：デフォルトの名無しさん：2015/11/08(日) 13:11:15.37 ID:+/vDw/dU: とりあえず試してみた

上がデフォルトの設定で下が高dpiを有効にしたもの
正直WPFでやったほうが楽だと思う
スレ違いになるので調査はここまで
462 ：デフォルトの名無しさん：2015/11/08(日) 14:16:08.80 ID:dTi+2HoB: また一つWPFの優位性が崩れたなw
463 ：デフォルトの名無しさん：2015/11/08(日) 14:40:16.82 ID:kntbqbdL: System DPI AwareになっていないWinFormsを勝手にボケんなやとスケーリング解除すると
大抵の場合めっさレイアウト崩れるのなんなんやろね
464 ：デフォルトの名無しさん：2015/11/08(日) 15:06:26.33 ID:Qhkwq36G: >>463
コントロールの配置座標の計算が腐ってるんだろうな
MSが放置してるのは互換性の問題かなんかあるからかな？
>>461で作ったデフォルトの設定のフォームもスケーリングを無効にすると
レイアウトが酷いことになるｗ
465 ：デフォルトの名無しさん：2015/11/08(日) 15:22:34.11 ID:dTi+2HoB: 高DPIに対応してないとか言った低脳の謝罪はまだか?
466 ：デフォルトの名無しさん：2015/11/08(日) 16:26:56.35 ID:qWpIgAsz: 良く調べてないけど、要するにシステムの設定に関わらずアプリ側で
仮想DPIをOFFにできるようになっただけでしょ。

だとしたらやっぱりWindows Formの高DPI対応は不完全だよ。
Windows Formの座標系は物理的なピクセルであって、WPFのDIPみたいに抽象化されていない。
前にこの話題でVSスレで恥をかいた。
467 ：デフォルトの名無しさん：2015/11/08(日) 17:17:01.91 ID:tDUIUF5u: Win32APIの高DPI対応がWPFと違いが出ているのは仕方ないよ
不完全なのではなく根幹のアーキテクチャの違いの問題なので合わせようが無い
Win32APIではWin32APIなりの対応方法がなされているというだけ
468 ：デフォルトの名無しさん：2015/11/08(日) 23:42:57.08 ID:HD25ztTo: >>465
申し訳御座いません。電信柱が高いのも郵便ポストが赤いのも
VWが排ガス不正したのも旭化成が杭打ちデータ偽造したのも東芝の不正経理も
全て私の責任です。
469 ：デフォルトの名無しさん：2015/11/09(月) 09:41:46.21 ID:jOZfZmiI: デスクトップアプリは将来なくなるだろうな。まだ少し先の話だろうけど。
XAMLはほんと嫌い。HTML+SCSS並の利便性が欲しい。
470 ：デフォルトの名無しさん：2015/11/09(月) 11:55:45.12 ID:hqP7pMYo: 無くなるか？
無くなるとしたら他の何を使うの？
タッチ前提のスマホアプリ？スマホアプリで仕事するの？
マウス使わずにタッチで仕事するの？
471 ：デフォルトの名無しさん：2015/11/09(月) 12:20:49.96 ID:T7Bex7XJ: >>469
Windowsが有る限り消えないだろ
472 ：デフォルトの名無しさん：2015/11/09(月) 12:58:24.52 ID:eIzs0U/u: だいたいここで薀蓄を垂れている奴がどんな凄いformアプリを作れるのか見てみたいにもんだわ。
473 ：デフォルトの名無しさん：2015/11/09(月) 13:51:13.99 ID:hqP7pMYo: DBからデータ拾ってきて表示するだけのアプリです
474 ：デフォルトの名無しさん：2015/11/09(月) 13:57:19.43 ID:Qq955bYP: そんなブーメラン食らいそうな煽りせんでも
475 ：デフォルトの名無しさん：2015/11/09(月) 14:08:59.75 ID:kkZjtYEf: デスクトップアプリを作るのにWPFでなければならない理由が皆無
上で話題に上がってる高dpiがなんてのは無しだぜ
大多数のデスクトップアプリは対応してないからな
むしろそれで問題が発生するならそれは互換性を維持できていないOS側が悪いのだからな
476 ：デフォルトの名無しさん：2015/11/09(月) 14:24:40.75 ID:jOZfZmiI: >>470
>>471
Webとデスクトップが融合していくのは間違いない。今既にChromeの
ようなブラウザが単なるブラウザの枠を越えてデスクトップ空間にまで浸食
してきている。俺はブラウザがあらゆるアプリのハブになっていくだろうと思ってる。
今後多くのアプリがブラウザとの親睦性を強いられてくるだろう。その時、
クロスプラットフォームに不利なデスクトップアプリは次第に消えていき、
多くのアプリがHTMLとそれに関連する言語にシフトしていくと思う。

あまり長々と書きたくないんだが、VRとARが普及する未来を想像すると
Googleはかなり先を見てそうだなってのは感じる。
その点、ストアアプリなんか押しちゃうMSなんかはお先真っ暗だわね
477 ：デフォルトの名無しさん：2015/11/09(月) 14:31:31.13 ID:R1pq0tYr: >>476
何度も言うけど、その手の話は別に目新しい話じゃなくて前世紀の終わりから何度も語られてる「見果てぬ夢」。
こういう歴史を知らないお馬鹿さんだけがその手のヨタ話を真に受ける。
478 ：デフォルトの名無しさん：2015/11/09(月) 14:36:19.05 ID:R1pq0tYr: っていうかさあ、これからは簡単な仕事はブラウザで何でもできる時代だ、とか言われてもう10年近いけど、
結局ほとんどの人はせいぜいwebメールぐらいしか使ってない。
479 ：デフォルトの名無しさん：2015/11/09(月) 14:47:36.51 ID:VsibgHt3: 誰もがネットに繋がる端末を持ってる今でもこの程度じゃんねえ
聞き飽きたシンクライアントの夢はインフラのブレイクスルーが起きてからまた語ってくだしあ
480 ：デフォルトの名無しさん：2015/11/09(月) 14:50:11.29 ID:Qq955bYP: ChromeOSがWindowsを駆逐すると大喜びで語ってた連中はどこ行ったんだろうな
481 ：デフォルトの名無しさん：2015/11/09(月) 15:02:24.30 ID:jOZfZmiI: >>477
>>479
昔の話をされましてもね。HTML5はまだ出たばかりだというのに。
ECMA6もPHP7も出るし、他にもまだあるだろう、Webは一大進化を遂げようとしているのだよ。
IoTやAIの時代も来てる。そんな中でもこれからも変わらないと信じるなら、もう何も言うことはないね…
482 ：デフォルトの名無しさん：2015/11/09(月) 15:08:40.56 ID:Qq955bYP: Webは万能ツールではないからな
どれだけ進化しても全てのユーザーの要望を吸収することなんか無理だよ
それが可能なのはWindowsやLinuxのような汎用性の高いOSだけ
483 ：デフォルトの名無しさん：2015/11/09(月) 15:10:43.26 ID:R1pq0tYr: >>481
2001年宇宙の旅って映画みたことある？
AIが実用化して間もなく人間の知的作業のすべてを代替するようになる、
って幻想は1960年代から定期的（20年周期ぐらい？）に語られてる。

日本でも80年代、莫大な国費を投入して第五世代コンピュータを研究したけど
結局成果は何も出せなかった。

今のAI騒動ここの茶番の繰り返し。
自動車会社なんか2020年までに自動運転の実用化なんて言ってるけど、ちょっとでも詳しい人で
これを真に受けてる人なんか誰もいないんじゃないの。

自動運転なんて恐らく2040年になっても実用化してないよ。
484 ：デフォルトの名無しさん：2015/11/09(月) 15:30:55.84 ID:jOZfZmiI: >>482
確かに完全消滅することはないだろうけど、ウェブアプリの数は今後も増加の一途を辿っていくだろうね
そしてブラウザはより多くをこなそうとしている。

>>483
昔からこう言われて今もこうだから将来もこんなもんという論理はどうかと思うね。
自動運転のことだけど、真に受けるの意味がよく分からないな。既にトヨタは高速での
試験走行に成功してるんだけど。グーグルカーは街中を自動で走ってるよ。
2020年にも高速なんかでは自動運転車が走るんだろう。
2040年なんて量子コンピューターの世界ですよ。ついでにいうとCNTの世界は数年後だよ
485 ：デフォルトの名無しさん：2015/11/09(月) 15:42:20.21 ID:hqP7pMYo: 釣り針の大きなドリーマーだな
企業はMSOfficeが必要だからWindowsしか無理
わざわざWindows以外のOSを選ぶリスクなんか背負い込むかよ
Windows以外といったらLinuxぐらいしか無いが、
そんなものをオフィースののコンピュータにインストールするわけがない
だったらわざわざWebアプリにする必要もないことがすぐに分るだろう
Windowsアプリの方が簡単で安上がりなんだからな
486 ：デフォルトの名無しさん：2015/11/09(月) 15:45:54.45 ID:hqP7pMYo: 仕事で使うアプリのどれか一つにでもWindowsアプリが必要なら
Windowsをインストールしなければならない
それで既にWindowsがインストールしてある状況なら
アプリもWindowsアプリで良い事になる
だからWindowsアプリが蔓延するし
Windowsアプリが蔓延したらよりいっそうWindowsしか選択肢が無いことになる
こういう理論で今までずっとMSの天下だったわけで、これからもそう
487 ：デフォルトの名無しさん：2015/11/09(月) 15:53:27.06 ID:Qq955bYP: 特にセキュリティにうるさい企業はWebアプリなんて論外だろうしな
488 ：デフォルトの名無しさん：2015/11/09(月) 15:54:42.96 ID:jOZfZmiI: >>485
ドリーマーでもいいですけど・・・
オフィースも今やブラウザでできるんですねえこれが
https://www.microsoft.com/ja-jp/office/365/product-officewebapps.aspx
ついでにChrome拡張なんかでも出してる
http://www.forest.impress.co.jp/docs/news/20151030_728295.html

一体この展開を数年前に誰が想像できてただろうね

>>486
デスクトップアプリの定義が怪しいかも知れない。Windowsがなくなるとは思ってないよ。
俺も信者ですし。ChromeOSの侵攻はあるだろうけどね。
将来VRとARの普及とその出来によってはOSの姿やワークスタイルが変わってくるとは思ってるよ。
489 ：デフォルトの名無しさん：2015/11/09(月) 16:13:11.26 ID:hqP7pMYo: そんなWeb版Officeで仕事が出来るとでも？
490 ：デフォルトの名無しさん：2015/11/09(月) 16:27:29.73 ID:hDkDA5dy: >>475
> むしろそれで問題が発生するならそれは互換性を維持できていないOS側が悪いのだからな
とは言え、Windows 10でも対応していないのだから、アプリ開発者側で対応する必要がある。
491 ：デフォルトの名無しさん：2015/11/09(月) 16:30:22.86 ID:jOZfZmiI: >>489
さあ。それよりウェブアプリの侵攻に目を向けてもらいたかったね。
492 ：デフォルトの名無しさん：2015/11/09(月) 19:10:57.53 ID:hqP7pMYo: Web版VisualStudioが有っても使うわけないし
ただでさえWPFになったせいで重くなったのに
493 ：デフォルトの名無しさん：2015/11/09(月) 19:33:31.36 ID:jOZfZmiI: >>492
VisualStudio Onlineは既にあるし。あなた何も知らないのね。
それにあなたが使うかどうかなんてのは全く関係ないし、個別の案件を持ってこられても
俺は今後の情勢とWeb技術が進化を見せる中での将来の話をしてたわけで、
論点が違うし。全くお話にならないわね。
494 ：デフォルトの名無しさん：2015/11/09(月) 19:35:46.32 ID:hqP7pMYo: で、みんな使ってるの？
495 ：デフォルトの名無しさん：2015/11/09(月) 19:55:16.85 ID:jOZfZmiI: >>494
なんか全然理解してもらえてないね。スレ汚してる感じがしてこれで最後にするけど、
そもそもクロスプラットフォームでの開発に需要がないとでも？しかもそこは重要な
論点じゃないし。問題はWebアプリが今後より一層台頭してくるということにあるのだよ。
XAMLの余命はそんなに長くはないだろう。
そんな中でも今日も俺はWPFでプログラムを組んでるのだがね。ハハ。それじゃあね。
496 ：デフォルトの名無しさん：2015/11/09(月) 20:23:26.42 ID:jOZfZmiI: 最後と言ったけど1つ書き残しておこうと思う。
Chromeはアプリ業界全体に対してとっておきを残している。それを予見してるものはいるか。
これはWindowsが敗れ去るほどの威力を秘めてるぞ。
497 ：デフォルトの名無しさん：2015/11/09(月) 20:38:45.39 ID:eW5XCVAC: 未練タラタラっすね
女々しい
498 ：デフォルトの名無しさん：2015/11/09(月) 21:05:54.73 ID:RWgJx2iy: このスレで赤くなるまで頑張ってる人久々に見た
499 ：デフォルトの名無しさん：2015/11/09(月) 21:19:58.13 ID:NNngDstw: GoogleによるMS打倒を夢見た哀れな子羊の成れの果て
500 ：デフォルトの名無しさん：2015/11/09(月) 22:39:35.59 ID:hqP7pMYo: プリマルチプライ済みアルファって何やねん！って思いません？
変な事するな
501 ：デフォルトの名無しさん：2015/11/09(月) 23:04:57.07 ID:qhZ8wC2Z: っていうかさあ、川俣大先生じゃないけど、この業界を見て来た歴史が浅いと
>>496みたいな夢見る少年になっちゃうのはまあ仕方ない。

本物の革新とただのはったりの区別がつかないんだ。

15年ぐらい前のJavaの未来（笑）に陶酔してた奴らもこんな感じだった。
502 ：デフォルトの名無しさん：2015/11/09(月) 23:26:24.16 ID:1HE++DzE: Chromeもデスクトップアプリなわけだが
503 ：デフォルトの名無しさん：2015/11/10(火) 23:59:00.41 ID:3V9IVqNV: ChromeとWindowsって比べるようなもんなのか
504 ：デフォルトの名無しさん：2015/11/11(水) 00:30:02.09 ID:1POahPwI: 496は何か言ってましたよ
505 ：デフォルトの名無しさん：2015/11/11(水) 08:14:28.84 ID:IzPlk793: prismのErrorsContainerは格納されている全てのエラーを取得する方法がなさそうなのですが
モデル全体のエラーを取得するにはどのようにすればよいのでしょうか。
エラーの管理を基底クラスでやるのは間違ってますか？
506 ：デフォルトの名無しさん：2015/11/13(金) 01:32:18.68 ID:5ZkQwuSs: WPFで思いっきりコーティングしたいなあ
どののプロジェクトにいってもwinformばっかりだわー
デザイナファイル好きじゃないんよ
507 ：デフォルトの名無しさん：2015/11/13(金) 14:17:10.59 ID:58zMej98: WPFとか使いどころが無いんだよ
採用してもコストかかるだけでメリットないから採用されるはずがない
508 ：デフォルトの名無しさん：2015/11/13(金) 14:41:17.33 ID:+1eGYaPq: GPUを使うから速いんだよ！
MSが言っていたもん！

WPFで書き直された糞重いVS2010以降をMS自ら開発者に使わせといて
誰が信じるかよ
全くすごい説得力だったわ
509 ：デフォルトの名無しさん：2015/11/13(金) 15:02:35.64 ID:58zMej98: たしかにVS2010以降は妙に重いよなｗ
510 ：デフォルトの名無しさん：2015/11/13(金) 15:23:27.31 ID:P7CO1/9F: >>506
WinFormsから出たらついていけないやつばかりだから無理
511 ：デフォルトの名無しさん：2015/11/13(金) 22:04:28.88 ID:AaEDqy12: >507
言い過ぎ。
既存のGUIフレームワークっぽさを感じさせないGUIを作る必要がある場合は、断然WPFの方が楽。
そういう要求は稀かもしれなけど。
512 ：デフォルトの名無しさん：2015/11/13(金) 22:42:12.66 ID:+1eGYaPq: >既存のGUIフレームワークっぽさを感じさせないGUIを作る必要がある場合

まず仕事では殆どないだろうな
趣味でメディアプレイヤーやフォトビューアでも作るならアリかもしれんが
513 ：デフォルトの名無しさん：2015/11/14(土) 00:23:09.35 ID:aiL2pSlJ: >>512
ほとんどというか全く無い
514 ：デフォルトの名無しさん：2015/11/14(土) 01:53:53.18 ID:Qc99f8i6: 組み込みの仕事で使ったよ。
そっち方面は独自のGUIを要求されることも多い。
ただし、.Net自体使えないことも多いが。
515 ：デフォルトの名無しさん：2015/11/14(土) 07:46:29.22 ID:8LwFliI7: 俺が今までここ数年で仕事でWPF使ったことあるの

・医療用電子カルテ
・電子顕微鏡用画像処理ツール
・外資系投資顧問会社用の分析集計ツール

こんなとこだな
どれも、WPFでなきゃ作れない訳でもなく、必然性はなかったけど。
516 ：デフォルトの名無しさん：2015/11/14(土) 12:32:24.67 ID:CbtKXtTb: WinFormでFormの裏にベタ書きするのが未だに主流だし、VB6からの流れだからなあ
WPFを無理に使おうとしてもコードビハインドに書いてしまいそうだよね
プリズムとかリベットとか使ってMVVMで実装するとかは、一部のコーディングマニアの自己満足にしかなってないのが残念だ
好きなのに
517 ：デフォルトの名無しさん：2015/11/14(土) 16:52:57.23 ID:VcJqmaD3: 一番の問題はMS自身がやる気無いこと
518 ：デフォルトの名無しさん：2015/11/14(土) 23:39:52.61 ID:4DJaZdYa: >>515
全てどこの社か特定可能ｗ
あまり具体的に書かんほうがいいんじゃないか？
519 ：デフォルトの名無しさん：2015/11/15(日) 01:19:06.75 ID:6d3FFbb6: 自由度が故に使いにくいWPFアプリが多すぎる。
520 ：デフォルトの名無しさん：2015/11/15(日) 17:24:37.52 ID:SwaoEtt5: リストビューのアイテムにボタンを並べて
そのボタンの中に動画を表示できるぐらい柔軟性が有るからね
何でもかんでも入れ子に出来てレゴブロックみたいで楽しい
組み合わせは無限大
521 ：デフォルトの名無しさん：2015/11/15(日) 17:36:18.28 ID:yG4mfSw/: PC版nasneアプリがクソ重いと思ったらWPF製だった時の納得感よ
snoopで覗けて笑ったわ
522 ：デフォルトの名無しさん：2015/11/15(日) 20:08:09.74 ID:Ej5hNEpo: プレミア１２テレビ中継の得点用表示器が、どちらが攻撃中かを示す赤い下線がおかしなことになっている
多分全部完成した後に急遽線付けたんだろうね。他人事とはいえ何か身につまされるわ
523 ：デフォルトの名無しさん：2015/11/15(日) 20:14:26.58 ID:6d3FFbb6: いるよな。できてからあれこれ文句を言い出すジョブスみたいな奴。
どうするか設計時に聞いたら何も言わないくせに。
524 ：デフォルトの名無しさん：2015/11/15(日) 21:52:13.18 ID:z1ZM/Jdm: 契約外なら無視すればいいだろ
間抜けな契約してるからそうなるんだよド間抜け
525 ：デフォルトの名無しさん：2015/11/15(日) 21:58:49.13 ID:a85SZ0fm: >>523
逆にとても良いものだと部下から奪って自分のものにしてしまうってのもセットでなｗ
526 ：デフォルトの名無しさん：2015/11/15(日) 22:10:06.90 ID:Ej5hNEpo: プレミア１２の件は恐らく発注者のミスではあるが、運用上どうしても必要な機能だから
なんとかせざるを得なかっただろうね
で、結果デザイナー涙目の汚いプロダクトに成り下がったわけだ
527 ：デフォルトの名無しさん：2015/11/16(月) 02:42:19.23 ID:e1ef4c6Q: >>524
ジョブスと同じこと言ってやがるw
528 ：デフォルトの名無しさん：2015/11/16(月) 03:25:32.34 ID:QnJE0SEP: WPFはMSの文句どおり軽ければ良いんだけど実際には重いからなぁ
それだけでもハードルが有るよ
WPFが重い事はVSで実証済みだから開発者全員が知っているしなぁ
529 ：デフォルトの名無しさん：2015/11/16(月) 08:48:38.66 ID:+kqBjfb+: そんなに重いとはまったく思わないが、とにかくコードを書いた本人であっても後で見て
意図を読み取り難いんだよ。やたら冗長だし。

要するに保守性が悪すぎる。これで流行るわけがない。

MVVMも理想は分かるけど、本当に必要かね。
最低限MとVが分離されてればそれでほとんどの場合十分のように個人的には感じる。
530 ：デフォルトの名無しさん：2015/11/16(月) 08:50:05.64 ID:+kqBjfb+: あ、重いとは思わんけどただ（保持モードに固執してるせいで）グラフィック関係のパフォーマンスは糞悪いな。
531 ：デフォルトの名無しさん：2015/11/16(月) 09:59:01.84 ID:bfEVOxks: MVVMなんて気にしないで
フォームのようにイベント駆動でコードビハインドにベタ書きすれば楽
外見の柔軟性とデータバインドの手軽さのいいとこ取り
特に外見スキンを手軽に作れるのがいいな
他のプロジェクトに使い回しもできる
トリガー、ビヘイビアは面倒なのでやらない
532 ：デフォルトの名無しさん：2015/11/16(月) 10:24:58.88 ID:jAoHtzcc: クロスプラットフォームで利用できるようにしてから出直してこいって感じ
533 ：デフォルトの名無しさん：2015/11/17(火) 02:29:56.03 ID:M95COzQK: そもそも頻繁にUI変わんないor小規模の開発形態ならMVVMとかやる必要はない
ウォーターフォールもどき開発とか、帳票系みたいなのでMVVMが云々言ってる奴が時折居て、無駄だなあとか思う
534 ：デフォルトの名無しさん：2015/11/17(火) 04:22:49.83 ID:Zv9M4ofQ: 動的に内容が変わるUIって結構嫌われるんだよな。
535 ：デフォルトの名無しさん：2015/11/17(火) 17:25:08.93 ID:9TMnQxUV: WPFはiPhoneなんかのヌルヌル動くUIを目指して作ったんだろうけど
Windowsでそんなことするメリットはどこにあるの？としか
536 ：デフォルトの名無しさん：2015/11/17(火) 18:57:21.11 ID:A3FVmbuJ: WPFができるちょっと前にリッチな外見のGUIブームがあった
javaのなんとかグラスとかappleもなにか作ってた気がする
カラフルだったり透き通ってたり3Dが活用されていたり
多くの人は未来を感じたと思う
次世代OSはこうあるべきみたいな流れだった
MSはそれに乗っかった

MSはコードネームlonghornのデモムービーですごいのを発表した
でもそれは完成できなくて全部作り直してVISTAとして出した
WPFはそのGUIを.netから実現する手段としてデビュー

後から見るとリッチなGUIは必須でも何でもなかった
実際に必要なのは手になじむ操作感だったというのを僕の嫌いなappleが教えてくれた
537 ：デフォルトの名無しさん：2015/11/17(火) 20:34:51.37 ID:dteVTBOb: シルバー何とかってどうなった
538 ：デフォルトの名無しさん：2015/11/17(火) 21:29:41.69 ID:lYlDUfoh: ご老体は引退しましたよ
539 ：デフォルトの名無しさん：2015/11/18(水) 03:18:35.54 ID:D/530RSj: リボンUIやメトロUIが未だに嫌われてるからな。GUIは凝れば凝るほどウザがられる。
540 ：デフォルトの名無しさん：2015/11/18(水) 11:22:18.46 ID:gfMg4p1S: リボンもメトロも使い勝手を悪くしただけだしな
541 ：デフォルトの名無しさん：2015/11/18(水) 11:46:30.44 ID:zOBgdGWj: リボンまで否定するってどんだけロートルだよw
リボンUIは作る方の負担は大きいけど使い方のメリットはそれなりにあるぞw

ストアアプリもタッ前提のUIとしては悪くない。
（もちろんデスクトップのUIとしては論外だし、それをデスクトップユーザーにごり押ししたWin8.xの
方針は愚かとしかいいようがないが）

ただ、あまりにも原理主義的なフラットデザインはやっぱりダサい。
542 ：デフォルトの名無しさん：2015/11/18(水) 11:52:25.72 ID:gfMg4p1S: リボンはMSもそう思って進めたんだろうが実際は大不評だったわけだが
543 ：デフォルトの名無しさん：2015/11/18(水) 11:52:43.84 ID:s071DD2K: 541みたいなこの手の水差し野郎が一番普及を妨げてる
使いたくない奴なんかほっとけばいいのに、無様に食い下がるんだよな
暇なのか？
544 ：デフォルトの名無しさん：2015/11/18(水) 12:01:25.01 ID:zOBgdGWj: >>543
良い物は良い、悪い物は悪いんであって、リボンUIは悪くないよ。
お前さんみたいな食わず嫌いや適応能力の欠如はお前さん自身の問題であって
リボンUIの問題じゃない。

ただ、たとえ慣れれば大半の人が改善を実感できるものであっても、それをごり押しするのは
製品のデザインとしては良くないのは確かだけどね。

その点Office2007でのやり方はかなり愚かだった。
545 ：デフォルトの名無しさん：2015/11/18(水) 12:03:30.81 ID:zOBgdGWj: 実際問題、ユーザーはソフトを使って仕事をするのが目的であって、
ソフト自身の使い方をまた1から覚えるなんて面倒以外の何物でもないからな。
546 ：デフォルトの名無しさん：2015/11/18(水) 12:11:24.66 ID:D/530RSj: リボンUIの一覧性の無さは致命的だと思うけど。
やはり、メニューバー+ツールバー+ステータスバーがUI史上ベストの選択だよ。

なによりそれを一番理解してるのが開発してるMSの開発者。VSはリボンUIじゃない。
547 ：デフォルトの名無しさん：2015/11/18(水) 12:25:21.62 ID:zOBgdGWj: >>546
プロが使う開発ツールに向いてないのは確かだ。
っていかVSでツールバーなんてまず使わないしw
ほとんどキーボードショートカット時々メニューだしw

一覧性云々は何のことだか分からんね。
リボンUIはメニューと同じようにコマンドを分類でき、ツールバーより視認性を高くできる。
単純なツールバーでは実現できない複雑なコマンドの実装も可能だ。

リボンUIの問題点の一つはカスタマイズ性の低さだけど、Office2010以降はある程度のカスタイマイズが
可能になった。
548 ：デフォルトの名無しさん：2015/11/18(水) 12:27:22.11 ID:KhHecEDM: 作る側がどう思うかではなく使う側がどう思うかだからね
使う側に不評ならそれは失敗作
549 ：デフォルトの名無しさん：2015/11/18(水) 12:28:28.12 ID:s071DD2K: 適応力などという話はしてないだろ
拒否している奴に執拗に使わせるのは時間の無駄だと言っている

俺に反論する前に小学校から日本語学びなおしてこい痰壷野郎
550 ：デフォルトの名無しさん：2015/11/18(水) 12:33:02.37 ID:zOBgdGWj: >>549
馬鹿かお前。
だから拒否してるのはお前自身の適応力の問題であってUIの機能性の問題ではない。
551 ：デフォルトの名無しさん：2015/11/18(水) 12:34:26.54 ID:s071DD2K: 猿に馬鹿かどうか語られる覚えはねえな
上野動物園で檻に入ってろ
552 ：デフォルトの名無しさん：2015/11/18(水) 12:34:30.60 ID:gfMg4p1S: >>548が言ってる通りユーザーの評価が全て
あれこれ御託を並べたところで意味は無い
553 ：デフォルトの名無しさん：2015/11/18(水) 12:38:15.21 ID:h5jOFP6A: ファンボーイの鏡だな。
天啓を受けて使命でも背負ってんのかと思う。
エバンジェリスト気取りでさ。
554 ：デフォルトの名無しさん：2015/11/18(水) 12:39:05.35 ID:3OuphFbm: まあ今OfficeのリボンUIを嫌う声もとんと聞かなくなったしそういうこっちゃな
555 ：デフォルトの名無しさん：2015/11/18(水) 12:43:24.10 ID:zOBgdGWj: >>552
残念だけど、少なくともOfficeに関する限り、最初はリボンUI否定派が多かったが（俺自身そうだったし）、
今じゃリボン肯定派の方が圧倒的に多数派になってる。

何にでも否定的なバカが揃う2chですらそうだから。
556 ：デフォルトの名無しさん：2015/11/18(水) 12:53:42.73 ID:gfMg4p1S: リボンが素晴らしいとか言ってる人をリアルにお目にかかったことはないが
使いづらいが慣れたという人は大勢いるがな
557 ：デフォルトの名無しさん：2015/11/18(水) 12:54:04.77 ID:Rs25wnGc: 分かったから、お宅の真っ赤な顔にも美麗なビジュアルエフェクト適用してさ、昼飯に戻りなよ。
558 ：デフォルトの名無しさん：2015/11/18(水) 13:05:55.85 ID:D/530RSj: >>555
おれも開発者のリボン肯定派ははじめてだから少し意見が聞きたい。

リボンUIのどこかメニューバー+ツールバー+ステータスバーより優れてるの？

一覧性の無さ、場所をとる、文字情報を入れるスペースがほとんどない、
機能があることは分かってるのにどこにそれがあるか分らない、慣れるまで(機能がどこにあるか覚えるまで)がやたら時間がかかる、
コンテキストによってリボンが変化しすぎて、ユーザーには今どのコンテキストかさっぱり把握できない

とデメリットしか思いつかない。便利だというメリットが何も見当たらない。これらのデメリットが旧UIにはないんだよ。
559 ：デフォルトの名無しさん：2015/11/18(水) 13:14:45.68 ID:3OuphFbm: どうでもいいがリボンだからと言ってステータスバーが無くなってるの見たことねえど
560 ：デフォルトの名無しさん：2015/11/18(水) 13:58:01.17 ID:zOBgdGWj: >>558
プリンの味を言葉で説明するのは難しいが、食ってみれば一瞬で分かる。
グダグダ言ってないでワードかエクセルで数日仕事してみれば分かるよ。

それらの問題は（コンテキスト云々以外は）全部旧来のメニューとツールバーにも当てはまる。

特にメニューバー＋ツールバーで問題だったのは、ワードみたいに使用頻度が割と高いコマンドが多数あると
メニューだと階層をたどって目的のコマンドまでたどり着くのが面倒で、かといってツールバーをカスタマイズして
必用なコマンドを並べると、分類する機能がないために視認性が悪い上に、畳む機能もないので
貴重な作業領域をツールバーに占拠されてしまう。

リボンUIの利点の一つはこういう問題を解決すること。
必用な機能を分類して綺麗に畳むことが出来る。

っていうか、リボン登場してもう10年とかなるのにまだこんなろくに使いもせずに
グダグダ言ってる人いるんだね。
561 ：デフォルトの名無しさん：2015/11/18(水) 14:07:36.92 ID:eyPmmAxS: アプリの機能一覧が知りたかったり探したかったりした場合、メニューバーは良かった
文字で表示してあるからね
一方でアプリの全機がズラっと並んだツールバーも使い勝手が良かった

リボンはなんつーか中途半端
文字は少ないし切り替えなきゃならんし
562 ：デフォルトの名無しさん：2015/11/18(水) 14:14:28.19 ID:eyPmmAxS: いいたい事は
もっと文字で説明して欲しいこともあるし
切り替えずに使いたい事も有るということ
色々なシチュエーションが有るので
それに対応するためにメニューバーとツールバーに分かれていた
563 ：デフォルトの名無しさん：2015/11/18(水) 14:30:02.80 ID:FZwVjyKL: タブレットやノートPCをタブレットモードで使うときに、リボンUIに感謝するであろう
564 ：デフォルトの名無しさん：2015/11/18(水) 14:38:28.69 ID:mMSz5zI4: 生かされてることに感謝して死ねニート
565 ：デフォルトの名無しさん：2015/11/18(水) 16:19:05.70 ID:gfMg4p1S: 2003までのOfficeやVSはツールバーのレイアウトをある程度カスタマイズできるから
使いやすいように配置してたけどリボンはそれができないんだよな
566 ：デフォルトの名無しさん：2015/11/19(木) 00:04:16.47 ID:Qo/umcST: リボンはいいからWPF＋MVVMについて熱く語ろうぜ。つーかーオワコンなのかな…
567 ：デフォルトの名無しさん：2015/11/19(木) 00:41:29.00 ID:+GHctN84: 4年前ぐらいにオープンソースのコントロール開発が頓挫したころにもう進化はないだろうなと思った
一応asyncとかの開発は合ったけど…
568 ：デフォルトの名無しさん：2015/11/19(木) 02:39:27.22 ID:pMZsVAsr: >>566
っていうか、リボンUIに対応してることがWPFの（実は数少ない）アドバンテージの一つなんですが。
569 ：デフォルトの名無しさん：2015/11/19(木) 05:30:19.03 ID:i3Dxx5NH: WPFが普及しないのはリボンUIのニーズがないからとも言えるな。
570 ：デフォルトの名無しさん：2015/11/19(木) 05:44:19.66 ID:qlbuoPV2: リボンが売りだなんて思ってる時点でWPF素人なの丸出しw
571 ：デフォルトの名無しさん：2015/11/19(木) 07:55:59.75 ID:btQoS/xZ: リボンUIならMFCだって対応してるがな。
572 ：デフォルトの名無しさん：2015/12/10(木) 22:57:20.58 ID:OW+FgvM6: 過疎
573 ：デフォルトの名無しさん：2015/12/11(金) 09:43:21.75 ID:4ee6Czzl: すでにオワコンだから仕方ない
Silverlightみたいに開発中止もあり得るしな
574 ：デフォルトの名無しさん：2015/12/12(土) 21:08:01.42 ID:qDaXCKpw: てゆうことは、結局WinFormに戻る流れなのか？残念だなぁ…
575 ：デフォルトの名無しさん：2015/12/13(日) 22:04:36.07 ID:l5dzQjDh: WPFの掲げてるメリットって業務系には必要とされないのよね
576 ：デフォルトの名無しさん：2015/12/13(日) 22:08:15.21 ID:liGcPy84: MSがWPFを開発した意図が未だに謎。時期的にマカーが開発に入ってきた時期。
577 ：デフォルトの名無しさん：2015/12/13(日) 22:24:55.78 ID:9CuuD7En: >>576
エッセンシャルWPFの冒頭あたりに書いてあるよ
このスレの過去ログにも乗ってる
578 ：デフォルトの名無しさん：2015/12/13(日) 22:52:10.70 ID:S5USnmm8: 手抜き延命だけしてないで早く次のUIフレームワーク出せよボケ
579 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 09:33:51.22 ID:pKtVOj6o: WinRTという立派なものがあるじゃないか
これと同じことになってるけどw
580 ：名無しさん＠そうだ選挙に行こう：2015/12/14(月) 12:18:58.87 ID:negfdfUk: >>575
これが一番かな
581 ：デフォルトの名無しさん：2015/12/14(月) 22:34:30.09 ID:jCBCVTY3: WinRTも7向けのランタイム配ってくれたら移行を検討するのに、とか思ってたら今度はUWPだもんな。
新しいテクノロジ打ち出す間隔がどんどん短くなってきているが、MSは結局どうしたいんだろうな。
582 ：デフォルトの名無しさん：2015/12/14(月) 22:49:25.50 ID:ETDpPCfc: 結局のところ、Win32APIが一番安定しているよな
MS一番のロングセラー
583 ：デフォルトの名無しさん：2015/12/14(月) 23:41:15.36 ID:4KSibpeR: >>582
そいつが幅をきかせてるせいで、クロスブラッドフォームだなんだといっても、結局Win専用なんだよね
584 ：デフォルトの名無しさん：2015/12/14(月) 23:49:00.50 ID:ccU2pCxg: クロスブラッドフォームとか最強そう
585 ：デフォルトの名無しさん：2015/12/14(月) 23:54:22.49 ID:2mQvz88W: ＞クロスブラッドフォーム
ｶｯｺｲｲ…

実際に実装されているライブラリの出来は別として
WinRTの仕組みはちゃんとデスクトップにも導入して欲しいんだがなあ
Win32APIとして提供してきたレイヤーをWinRTで置き換えれば
ネイティブだのマネージだのと阿呆みたいに実装を分散させなくて済むだろうに
586 ：デフォルトの名無しさん：2015/12/15(火) 00:44:05.28 ID:8cpdaSjZ: Win32APIをカーネルを初めとするOSの中核部位から排除しつつ旧来のソフトウェア資産との互換性を維持なんて不可能だからな
ARMプロセッサ用ということで思い切って捨てたWindowsRTは見事に自爆したし
587 ：デフォルトの名無しさん：2015/12/15(火) 12:08:01.50 ID:Z+PgRVVd: WinRTにしたってWPFにしたって
最終的には水面下で何らかのCスタイルのAPIを呼び出すスタイルにしなければ仕方ないし
だったらその水面下で呼び出すCスタイルのAPIをWin32APIと別のAPIに置き換えるメリットは
互換性のことを考えたらMS的には全く無いからして
いつまでたってもWin32APIは残り続けるんだよな

.NetのアプリもC#の上から直接Win32APIを呼び出しているのは一杯あるし
ドライバ類もWin32APIに依存しているからして
Win32APIを無くすと全てが動かなくなるからWindowsが終わるしね
過去のソフトが動かないなら、Windowsの意味は無いし
みんなWineの有るLinuxに乗り換えるでしょう

MSもバカじゃないからそんなことするわけがない
588 ：デフォルトの名無しさん：2015/12/15(火) 13:58:43.47 ID:Z+PgRVVd: まー一時期はMSもWin32APIをレガシーなものとして捨てたいとか思っていたかもしれないが
ARM版のSurfaceが爆死して、WindowsPhoneもサッパリで
過去の資産が無ければWindowsなんぞ糞程にも売れないことが判明した今となっては
死んでもWin32APIだけは死守しなければならないと考えているだろうね
Win32APIをメンテし続けるだけで巨額の大金が入ってくるのだから
まさに飯の種だね
589 ：デフォルトの名無しさん：2015/12/15(火) 20:59:32.97 ID:FPjuV9pT: クロスプラットフォームと言いたかったんだごめん
590 ：デフォルトの名無しさん：2015/12/15(火) 21:00:39.59 ID:FPjuV9pT: ちげえクロスプラットホーム
591 ：デフォルトの名無しさん：2015/12/16(水) 00:31:26.67 ID:r9ejGnsb: しかし、win64の汚さはWPF同様大失敗と言える。
592 ：デフォルトの名無しさん：2015/12/16(水) 01:00:37.93 ID:pSPiaIie: growth platformsだったらいいのにナー
593 ：デフォルトの名無しさん：2015/12/16(水) 22:05:52.40 ID:vLIsuvBA: .NET Framework 4.6 インストール環境において正常に印刷できない場合があります
http://blogs.msdn.com/b/japan_platform_sdkwindows_sdk_support_team_blog/archive/2015/12/16/net-framework-4-6.aspx
594 ：デフォルトの名無しさん：2015/12/18(金) 20:15:30.25 ID:sxAFthix: >>591
ポインタサイズが違うだけでそのまんまWin32じゃないの?
Win64の汚さはWin32と同じだと思うが。
595 ：デフォルトの名無しさん：2015/12/21(月) 08:01:08.67 ID:XZX67pGD: それを汚いという。
64bit用システムフォルダがSystem32とか、64bitDLLなのにxxx32.dllとかもうね。
596 ：デフォルトの名無しさん：2015/12/21(月) 12:59:27.71 ID:sBVii0h4: >>595
名前を変えたら互換性が
597 ：デフォルトの名無しさん：2015/12/23(水) 23:10:21.51 ID:dqNtClUO: Windows 秘話: ディレクトリの長い歴史
https://technet.microsoft.com/ja-jp/magazine/ff955767.aspx

数多くの既存の 32 ビットプログラムでは、GetSystemDirectory 関数を呼び出すのではなく、
System32 ディレクトリのパスをハードコーディングしています。
このようなプログラムは、64 ビット Windows 用に再コンパイルされても、
System32 ディレクトリにアクセスして、64 ビットファイルを検出しようとします
(これはプログラムが 64 ビットにコンパイルされていることに起因する動作です)。
構成ファイルやレジストリに書き込まれるパスは、
32 ビットプロセスと 64 ビットプロセスの両方で使用できる必要がありますが、
システムディレクトリへのアクセスを要求するプログラムの対応ビットに応じて
適切なディレクトリを参照する必要があります。

Windows チームは、この混乱した状況から抜け出すため、
64 ビットシステムでは 64 ビットファイル、32 ビットシステムでは 32 ビットファイルを含むように
System32 ディレクトリを構成しました。
32 はディレクトリ名前の一部でしかなく、何の意味もありません。
これは、DVD がただの名前で、実際には何の意味もないのと似ています。
また、多くの大企業が、HSBC、KFC、BP、KPMG など、
過去には何か意味があったのかもしれませんが、今では形だけでしかない一連の文字列を、
会社の正式名称にしているのと似ています。

System32 は、"実行中のアプリケーションが対応しているビットに一致しているシステム DLL" の
ディレクトリを示す、やや奇妙な名前と見なすことができます。
このようなディレクトリには、実行環境に対応したファイルが含まれているので、
理想的には、SysExec ディレクトリと呼ぶのが適切です。

この話が難しいと感じた場合は、ディレクトリの役割が、
ほとんど名前とは関係ないことだけを覚えておいてください。
598 ：デフォルトの名無しさん：2015/12/24(木) 06:36:52.68 ID:GUwJsV2N: MSはほんと馬鹿だな。
599 ：デフォルトの名無しさん：2015/12/24(木) 08:34:18.13 ID:KQkP520X: >>597
日本じゃ普通にKFCじゃなくてケンタッキーと呼ぶけど、ケンタッキー州があるアメリカじゃこれはNGってなんだなと改めて思いましたわ
札幌ラーメンは札幌と略せないが、ラーメンしか無い喜多方は喜多方だけでラーメンと通じるのと近いのかな
600 ：デフォルトの名無しさん：2015/12/24(木) 08:40:46.33 ID:Pov5M8G0: ＞数多くの既存の 32 ビットプログラムでは、GetSystemDirectory 関数を呼び出すのではなく、
＞System32 ディレクトリのパスをハードコーディングしています。

こーゆーのもなぜかM$が悪いって事にされるんだよな
UNIXならこんなの「アプリのバグなんだからさっさと修正しろ」ってなるのに
601 ：デフォルトの名無しさん：2015/12/24(木) 08:58:21.01 ID:GUwJsV2N: 実際、System32をハードコーディングしてるコードなんか見たことないし、
そんな糞コード書いてる会社が32bitアプリは64bitOSで普通に動くのに、
自社アプリを64bitバイナリにリコンパイルなどするわけないし。

考えられる可能性はハードコーディングしてるのはMSのコードだろうってこと。
602 ：デフォルトの名無しさん：2015/12/24(木) 09:07:42.23 ID:v0lRLIEa: あなたはこんなコードがたくさんあった事実をご存じないようですね

if (osName.startsWith("Windows 9") ||
osName.startsWith("Windows Me"))
603 ：デフォルトの名無しさん：2015/12/24(木) 12:10:47.18 ID:swpDS+HL: 世の中くそなコードはありふれてます
604 ：デフォルトの名無しさん：2015/12/24(木) 12:22:58.48 ID:ljOtjDlX: >>602
MSはOSのバージョンで起動制限するなと言ってるが
605 ：デフォルトの名無しさん：2015/12/24(木) 12:26:50.58 ID:ysfB0nv4: が、何だ？
お前のママじゃねえんだから察してもらえると思うなよ
無視すんぞ
606 ：デフォルトの名無しさん：2015/12/24(木) 15:12:21.24 ID:OshOrYu+: でもUNIXのディレクトリ名も結構ひどいよね

なぜ，/var や /etc が /etc や /cfg というディレクトリ名ではないのか？
http://d.hatena.ne.jp/ytakano/20100715/1279219401
607 ：デフォルトの名無しさん：2015/12/24(木) 16:00:08.42 ID:6vNSqUhp: >>605
それは格助詞止めにて御座います。
拙者の稚拙な文章により、あなた様の誤解を招いたことは拙者の不徳の致すところ。ここ上はこの場でこの腹かっさばいてお詫び申し上げますっ。
何卒ご容赦を～
608 ：デフォルトの名無しさん：2015/12/24(木) 20:41:50.26 ID:DECH3WsR: >>601
仮にハードコーディングしている過去のコードが有ったとしても
64bitでコンパイルし直す段階で直せば良いだけに思えるよな
明らかに動かないんだから修正忘れってことも有りえんだろう
ソースコードが紛失していたら修正できないけど
64bitでコンパイルし直すことが出来るってことは
ソースコードは有るわけだから修正可能だよなぁ
609 ：デフォルトの名無しさん：2015/12/24(木) 20:45:04.53 ID:DECH3WsR: 第一、system32をハードコーディングしているような物が
コンパイルオプションを64bitに変えただけで一発で動くわけないんだよな
どうせポインタは32bitって決めつけて書いているだろうからな
それの修正に比べたらsystem32のハードコーディングを直すぐらい何の手間でもないわけでな
MSの言い分はやはりおかしいと思うね
610 ：デフォルトの名無しさん：2015/12/24(木) 21:23:46.98 ID:aoyUltuH: ＞それの修正に比べたらsystem32のハードコーディングを直すぐらい何の手間でもない

そう思ってくれる人ばかりなら苦労はないんだよ…
611 ：デフォルトの名無しさん：2015/12/24(木) 21:33:39.22 ID:J8RdFq1O: 変更箇所がより少なくなるような選択をしたってだけだしそんなへんかねえ
内部だけじゃなく外部から直パス渡されたりする場合だってあるわけだ
612 ：デフォルトの名無しさん：2015/12/25(金) 06:50:29.10 ID:zqVhC3rj: 32bitアプリを単に64bitにリコンパイルしただけでは、大して速度は速くならないし、
単純には2GB以上のメモリを使えるようにはならないから、必要性が感じられないな。

アプリ側の変更箇所ではなく、OS側の変更箇所を少なくしたかったんだろう。すなわちMSの手抜き。
613 ：デフォルトの名無しさん：2015/12/25(金) 06:57:25.53 ID:WO88kms8: >>612
作る方としては過去のしがらみを捨てて新API作った方が楽だぞ。
過去との互換性を保証するなんて泥臭い事はしたくない。
614 ：デフォルトの名無しさん：2015/12/25(金) 07:04:42.32 ID:zqVhC3rj: System64、xxx64.dllにして互換性がなくなるとか意味が分らない。
System32、xxx32.dllは32bitバイナリ動かすために残るんだげど。
ハードコーディングしてるアプリはリコンパイルしなければそのまま動く。めっちゃ楽。
615 ：デフォルトの名無しさん：2015/12/25(金) 09:31:59.26 ID:mbYDDRFn: MSの手抜き(笑)
SysWOW64なんてフォルダをわざわざ作って、
32ビットプロセスからはこれがSystem32に見えるような事やって、
逆にオリジナルのSystem32を32ビットプロセスから見たい時のために
SysNativeなんてのを用意するような面倒な事やってるのに?
MSからしたらSystem64みたいなのを追加したほうが楽だったと思うぞww

ファイルシステムリダイレクタ
https://msdn.microsoft.com/ja-jp/library/aa384187(v=vs.85).aspx
616 ：デフォルトの名無しさん：2015/12/25(金) 09:49:53.92 ID:zqVhC3rj: SEが無能馬鹿でPGでその尻拭いしたよくあるパターン。
617 ：デフォルトの名無しさん：2015/12/25(金) 20:47:15.84 ID:XvkCqMEu: >>614
>System64、xxx64.dllにして互換性がなくなるとか意味が分らない。

互換性は関係ないだろ
どうせ、64bitアプリからは32bitDLLは読み込めないし
逆もまた然りなんだからな
64bitでコンパイルし直すときにハードコーディングしている部分を直せばよいだろ、良い機会だ

>ハードコーディングしてるアプリはリコンパイルしなければそのまま動く。めっちゃ楽。

これも言っていることが良くわからないよね
再コンパイルしない32bitアプリがそのまま動くのは当たり前だろ
sysytem32を読みに行くのだからな
まさかsystem64を読みに行くわけないし
618 ：デフォルトの名無しさん：2015/12/25(金) 22:09:18.60 ID:tLqIdYkj: >>617
世に出回ってるソフトの大半はそんな気軽に修正だのコンパイルだのしてとかできないからね
個人が趣味で作ってるものばかりじゃないんだよ
619 ：デフォルトの名無しさん：2015/12/25(金) 22:25:57.80 ID:vhwK2AYw: コンパイルしなおさなきゃ32bitのままだろｗ
620 ：デフォルトの名無しさん：2015/12/25(金) 22:40:39.77 ID:hK6V4eA3: 反論のための反論になってきたでおじゃる
621 ：デフォルトの名無しさん：2015/12/25(金) 23:03:32.22 ID:MskxYtXc: System32に文句言ってるやつは世の中の開発者のレベルをもっと知るべき

互換性の問題への対処
https://technet.microsoft.com/ja-jp/magazine/2006.11.windowsconfidential.aspx
接合ポイントの機能不全
https://technet.microsoft.com/ja-jp/magazine/ee851567.aspx
アプリケーション互換レイヤーは顧客のためにあるのであり、プログラムのためにあるのではない。
http://blog.livedoor.jp/niwatori_atama/archives/51744454.html
デスクトップ上のアイコンは固定できないよ
http://cpplover.blogspot.jp/2009/12/oldnewthing.html
戦うプログラム
http://cpplover.blogspot.jp/2010/11/old-new-thing.html
622 ：デフォルトの名無しさん：2015/12/26(土) 06:42:17.88 ID:uEzrK5xR: 開発者のレベルを考慮しないで開発したのがWPFです。ついてこれない人多すぎです。
623 ：デフォルトの名無しさん：2015/12/26(土) 09:03:23.79 ID:/nyBzers: 完全にWPFの話から離れてるよなあ
と思ってたら戻ってきたww
624 ：デフォルトの名無しさん：2015/12/27(日) 00:19:31.21 ID:3ybqp/HF: >>622
そうかなあ
そもそも作ったやつが馬鹿なんだsと思うぞ
WPFってPrismとかUnity使ってもまともに作りづらいだろ
Prismもクソだけどな

なんでこんなクズみたいな仕組みを使わないといけないのか残念で仕方がない
後継もUWPみたいなクズだし
625 ：デフォルトの名無しさん：2015/12/27(日) 00:21:15.62 ID:3ybqp/HF: 酔ってて間違えた
すまん
626 ：デフォルトの名無しさん：2015/12/27(日) 00:40:20.69 ID:6NYNO2+5: MVVMってのが問題なんじゃない？
世間一般の業務アプリは必要としてないんじゃ
627 ：デフォルトの名無しさん：2015/12/27(日) 01:48:49.03 ID:isAqOdFe: Visual Studio CodeをWPFで作ってみろってんだ

WPFの採用事例ってひょっとしてJavaのSwingよりも低い？
628 ：デフォルトの名無しさん：2015/12/27(日) 03:11:09.45 ID:pJIBBhpC: 作ってみろってかWindowsべったりで良いならそっちの方が楽だったでしょ
VSエディタの実装が既にあるんだから
629 ：デフォルトの名無しさん：2015/12/27(日) 09:07:14.04 ID:dVF8TAp1: 新しいこと覚えようとする人少ないからなー
WinFormsが無くなるまで覚えようとはしないよ
630 ：デフォルトの名無しさん：2015/12/27(日) 10:05:10.00 ID:wi/WwQPq: 新しく登場したWinformsで挫折する奴はいなかった。むしろみんな簡単楽チン、C#最高という雰囲気だった。
それに比べてWPFは面倒、遅い、キモイだからなぁ。
631 ：デフォルトの名無しさん：2015/12/27(日) 20:06:37.79 ID:p7M6Fp1Q: MVVMもイベントモデルも使えるんだけど、イベントモデルで最初立ち上がればいいと考えたのに
何故か簡単なイベントモデルさえ拒否られたのは謎だ
632 ：デフォルトの名無しさん：2015/12/27(日) 20:29:34.23 ID:NH+KDjDi: デザインパターンに縛られる人なんでしょ
使うんでなく使われてるのね
633 ：デフォルトの名無しさん：2015/12/27(日) 20:51:01.30 ID:p7M6Fp1Q: VB6以前の時代だと、コボラー上がりの人たちがコボルの作法で糞コード量産していた時とは全く違うのは不思議だ
アレと同じようにWPFでもイベントモデルで作ればよかったんだよな
634 ：デフォルトの名無しさん：2015/12/28(月) 00:49:59.94 ID:5CzIwwWj: 別にコードビハインドでやればWinFormsと似たものなのになあ。
XAMLだって貼り付けだけなら同じだし。
でもやる人すくない。
635 ：デフォルトの名無しさん：2015/12/28(月) 11:18:36.83 ID:BB6eSvFu: まぁそうだなぁ。コードビハインドで全部入りゴッドクラスやったらええねんｗ
636 ：デフォルトの名無しさん：2015/12/28(月) 11:56:24.67 ID:yBuy0GzU: >>634
それでもWPFの方がいいと思うけどなあ
Winformのデザイナの勝手に書き換えられるとこがどうにも好きになれん
コードで画面組み立てるのに慣れた方が、他の言語触るときのことも考えたら、いいと思うんだけどねえ
637 ：デフォルトの名無しさん：2015/12/28(月) 13:52:58.78 ID:9UAY+TGH: 今更、30年前に戻れと言われてもねぇ。
638 ：デフォルトの名無しさん：2015/12/28(月) 13:59:06.82 ID:oov8U8z8: WPFは標準のライブラリがいまいちなんだよな
かといってOSSでいいものが見当たらない
ｈｔｍｌ5やjsは開発環境がいまいちだけどいろいろと面白いライブラリがあって
楽ができたり最新技術楽しめたりする

WPFはもういろいろと見放されすぎてて面白みがない　
639 ：デフォルトの名無しさん：2015/12/28(月) 17:08:50.26 ID:qm2ajh4N: >>636
前も書いたかもしれんけど、WPFっていうかXAMLでもコード書いてるその時はいいんだけど、
致命的なのは後で見なおした時とか他人の書いたコードを見た時に何をやってるのか意図を理解するのに
ものすごく時間が掛かるんだよなあ。

要するに可読性が悪すぎ。

他にもパフォーマンスの問題とかもあって、利点を欠点が上回っちゃってるから
ほとんどの場合多少不自由でもWindows Formの方がましだって結論になっちゃう。
640 ：デフォルトの名無しさん：2015/12/28(月) 19:39:31.26 ID:8SAtAt1A: >>639
可読性が悪いと感じるのは慣れていない所為。
と思いながらやってます(´・ω・`)

HTMLならHTMLがUI部品、スタイルシートが見た目・装飾、JavaScriptが可動(クライアントサイド)と
棲み分けしていたのをすべてXAMLでまかなおうとするから、なんか歪に感じる。
一連の動作がどの様に連なって処理されているのか追いにくい、ある意味スパゲッティコード。

せめて定義部分の<head>とUI部分の<body>で分けていた方がすっきりしたようなと思わなくもない。

本当にこの先があるのかと疑心暗鬼になりつつ、慣れる(正しく理解する)までは馬鹿正直に
MVVM至上主義でやるのもいいんじゃないのか。融通を利かせるのはその後で。
641 ：デフォルトの名無しさん：2015/12/28(月) 19:46:01.63 ID:JJlxJ852: DataBindingは至る所で使われるようになった
Commandは似た方式を採用したという話を聞かない
Behaviorも聞かない
642 ：デフォルトの名無しさん：2015/12/28(月) 20:11:55.21 ID:9UAY+TGH: 慣れたら使い易いは使い難いと40年近く前から言われてるPGの格言である。
643 ：デフォルトの名無しさん：2015/12/28(月) 20:50:28.06 ID:8SAtAt1A: BehaviorはAjaxとか騒がれ始めた時にわらわら出てきてたな。
Commandって視点をややかえたイベントみたいなものでしょ?

だから、PHPでHTMLやJSON吐きながら、JavaScriptでゴリゴリやっている俺なら
WPFなんてかるいかるい!

あ、あまかった...orz
644 ：デフォルトの名無しさん：2015/12/28(月) 23:10:37.76 ID:+mraESXV: 部分的にｃｓｓみたいに分かれていたらいいんだけどな
全部XAMLに詰め込まれててつらすぎる
645 ：デフォルトの名無しさん：2015/12/29(火) 20:14:26.49 ID:spshYaEB: で、そろそろ　per-monitor-dpi　には対応したの？
646 ：デフォルトの名無しさん：2016/01/03(日) 14:36:01.97 ID:kxchyzgG: pageクラスの共通base classを定義したくて、
xamlの
<page
x:class=pagederivedclass...
を
<local:pagebase
x:class=pagebasederivedclass…
に変更したのですけど、
InitializeComponentの定義が含まれてないよ！って怒られてしまいます…

どなたか解決方法わかりませんか？
647 ：デフォルトの名無しさん：2016/01/03(日) 16:04:53.03 ID:kxchyzgG: うわ、元に戻してもクリーンしても治らない…
何これ>_<
648 ：デフォルトの名無しさん：2016/01/03(日) 19:49:54.05 ID:HZupumAR: >>647
binフォルダとobjフォルダを空にする。

>>646とは違う別の要因だったが、Behaviorあたりで丸一日ハマったわ(´・ω・`)
649 ：デフォルトの名無しさん：2016/01/03(日) 19:57:44.07 ID:eQNYxzmQ: TextBoxのTextをUpdateSourceTrigger=LostFocusでやった場合
カーソルがTextBoxにある間にWindowを×で閉じると
WindowのClosingよりも後にLostFocusが起きてバインドプロパティが更新されるのですが
先にLostFocusがされるようにできませんか？
UpdateSourceTrigger=PropertyChangedにはしたくないです。
650 ：デフォルトの名無しさん：2016/01/03(日) 20:35:29.06 ID:NsMythuW: あきらめれば？
651 ：デフォルトの名無しさん：2016/01/03(日) 23:14:59.26 ID:kxchyzgG: >>648
レスありがとうー！

原因はpagebase作成のついでにpagebasederivedclassのフォルダを変更したのだけど、
それに伴ってnamespaceを変更し忘れていたことでしたorz
エラー出力内容からは想像もできず、1日無駄に使ってしまいました…>_<
652 ：デフォルトの名無しさん：2016/01/04(月) 13:42:08.77 ID:xNq31TCH: >>649
何に困ってるのか今一つ解らない。
プロパティが更新できてるなら、それでいいんじゃね？
653 ：デフォルトの名無しさん：2016/01/04(月) 15:51:49.65 ID:fLo7MfeV: 後処理の設計をフレームワーク側に合わせるのが筋。
654 ：デフォルトの名無しさん：2016/01/04(月) 18:46:18.66 ID:cZVD4jv0: >>652
Closingで保存したかったんす
655 ：デフォルトの名無しさん：2016/01/04(月) 19:14:44.31 ID:UrEM8qI9: closingはキャンセル可能なのにそこで保存するかっていう
656 ：デフォルトの名無しさん：2016/01/04(月) 20:30:48.19 ID:cZVD4jv0: Closedがありましたね
しかしなぜかClosedのほうが先に来るんですよね・・・
確認のためテストでWPFプロジェクトつくってTextBox貼り付けただけではClosedのほうが後にきました
今の作りがおかしいようです
作り方を変えます
657 ：デフォルトの名無しさん：2016/01/05(火) 14:35:11.17 ID:+sBwlcTA: >>656
自分が試した範囲ではたしか無理だった。
どうしてもClosedで処理したいなら
バインドじゃなくてTextプロパティからとるしかなったと思う
658 ：デフォルトの名無しさん：2016/01/05(火) 14:57:25.19 ID:WRneih8/: >>656
Keyboard.FocusedElementでフォーカス要素を取得
GetBindingExpression(TextBox.TextProperty)でTextプロパティのバインディングを取得
UpdateSourceでソースを更新
659 ：デフォルトの名無しさん：2016/01/05(火) 20:33:33.39 ID:BPcMibDv: closeイベントで保存する発想自体が何か違う気がする。
660 ：デフォルトの名無しさん：2016/01/05(火) 22:33:42.11 ID:T4MgNBSX: いやでも閉じた時の画面位置とか保存するときは普通にformのclosedイベント使うでしょ
661 ：デフォルトの名無しさん：2016/01/06(水) 00:16:08.04 ID:enD+OwOV: 是非はともかく、Closeの処理をBeginInvokeでやっつけたらなんとかなりそうだ
662 ：デフォルトの名無しさん：2016/01/06(水) 01:13:32.24 ID:gGKdTN41: ？？なんで閉じる時の処理でスレッド使うんだ？勉強不足で申し訳ないが
663 ：デフォルトの名無しさん：2016/01/06(水) 01:15:03.01 ID:gGKdTN41: あ、失礼、BeginInvokeでcloseすんのね
それはそうかも
664 ：デフォルトの名無しさん：2016/01/28(木) 23:26:28.22 ID:V7AL+xY1: 久々にWPFやったら結構忘れてる
これのbindした値が表示されないんだけど、何が悪いかわかりますか？
PersonクラスはAgeとNameのプロパティを持っています。
Personクラスのコレクションをバインドしています。

<Window.Resources><ResourceDictionary>
　<CollectionViewSource x:Key="cvs" Source="{Binding}">
　　<CollectionViewSource.GroupDescriptions>
　　　<PropertyGroupDescription PropertyName="Age" />
　　</CollectionViewSource.GroupDescriptions>
　</CollectionViewSource>
</ResourceDictionary></Window.Resources>
<Grid>
　<ListBox ItemsSource="{Binding Source={StaticResource cvs}}">
　　<ListBox.Resources>
　　　<DataTemplate x:Key="tmpHeader">
　　　　<Grid><TextBlock Text="{Binding Age}" Foreground="White" Height="18" Background="#FF818181"/></Grid>
　　　</DataTemplate>
　　</ListBox.Resources>
　　<ListBox.GroupStyle>
　　<GroupStyle HeaderTemplate="{StaticResource tmpHeader}"/>
　　</ListBox.GroupStyle>
　　<ListBox.ItemTemplate>
　　　<DataTemplate>
　　　　<TextBlock Text="{Binding Name}" Height="18" VerticalAlignment="Top" />
　　　</DataTemplate>
　　</ListBox.ItemTemplate>
　</ListBox>
</Grid>
665 ：デフォルトの名無しさん：2016/01/29(金) 01:01:13.69 ID:0MHdh4gn: まさか
<CollectionViewSource x:Key="cvs" Source="{Binding Persons}">
って落ちじゃないと思うが、ここで言うPersonsがPublicになっていないってのがありがちなミス
666 ：デフォルトの名無しさん：2016/01/29(金) 10:41:36.77 ID:NJXb4VpO: バインドはできていて、リストボックスにアイテムがPersonの個数だけ表示されるんですが、Nameなどに何も表示されていないんです
667 ：デフォルトの名無しさん：2016/01/29(金) 22:25:17.76 ID:0MHdh4gn: >>664
とりあえずGroupStyleでバインディングしているのはAgeじゃなくてNameが正解
グループのところではItemじゃなくてItemをグループ化したオブジェクトがバインドされるから
Name=グループ化したプロバティーとかCount=グループ内の個数をグループで表示できる

ItemTemplateのほうは良さそうに見えるからVMの問題かも知れんね
668 ：デフォルトの名無しさん：2016/01/30(土) 02:06:52.63 ID:l8kRrl6l: >>667
原因がわかりました。
Nameがプロパティじゃなくて、ただの変数になっていたことがNameが表示されない原因でした。
GroupStyleのほうは、てっきりAgeじゃなくて、Items[0].Ageで表示することができました。
WPFのことを話せる場所がまったくなくて困っていたのですが、とても助かりました。
669 ：デフォルトの名無しさん：2016/01/30(土) 08:52:46.21 ID:AQYvhDzr: >>668
WPFはネットで探してもあんまり見かけないものね…。ましてやSilverlight…
670 ：デフォルトの名無しさん：2016/02/01(月) 17:27:12.27 ID:SaEDCxUY: UWPはもっと酷いぜｗ
671 ：デフォルトの名無しさん：2016/02/02(火) 12:00:06.08 ID:OBgcOcZf: まだ普及してないのか、WPF。金貰わなきゃWPF使いたくないんだな、開発者は。
672 ：デフォルトの名無しさん：2016/02/02(火) 12:02:51.56 ID:jZDM0b/G: いつか普及するような言い方は止めろよ
673 ：デフォルトの名無しさん：2016/02/02(火) 19:32:05.12 ID:lBOfhJC6: キサマこそ口を噤め　いつ普及しないって証拠だよ？
674 ：デフォルトの名無しさん：2016/02/02(火) 19:51:22.48 ID:rrSwo6yy: UWPでWPF復活
675 ：デフォルトの名無しさん：2016/02/02(火) 21:49:44.27 ID:+IXosVRS: 俺もuwpには期待してるが企業はほとんどwin7使ってるから
普及に後3年はかかると思われ。
676 ：デフォルトの名無しさん：2016/02/02(火) 21:52:36.11 ID:jZDM0b/G: 強制アップグレードで先制パンチだ
677 ：デフォルトの名無しさん：2016/02/02(火) 23:47:12.56 ID:+grYMTZ/: >>673
ネタにマジレス・・・の前に、日本語不自由すぎるぞｗ
678 ：デフォルトの名無しさん：2016/02/03(水) 01:31:04.48 ID:XlUab3Me: 共通で読み込んでるスタイルにターゲットタイプが指定してあるスタイルがあります。
これをスタイルが適用されないようにすることってできますか？
スタイルを読み込まない以外で。
679 ：デフォルトの名無しさん：2016/02/03(水) 11:32:13.03 ID:xDVbB+Uh: その特定の画面でグループにして、再定義したらソッチ使われるんじゃね
680 ：デフォルトの名無しさん：2016/02/03(水) 11:34:56.36 ID:xDVbB+Uh: グループじゃねーや。マージか
681 ：デフォルトの名無しさん：2016/02/03(水) 12:56:23.90 ID:lK8o0nIc: それだとその画面でデフォルトのスタイル定義し直さないといけなくない？
上書きするならそれしかないかもだけど
682 ：デフォルトの名無しさん：2016/02/03(水) 17:34:03.76 ID:QYoF/S2v: WPFのアプリでウインドウサイズ固定が多い。自由度が逆に面倒で手抜きするPGが多いみたい。
683 ：デフォルトの名無しさん：2016/02/03(水) 22:47:01.55 ID:Nf+8Nu/F: 自由度高い()割に、凝ったことをしようとするとWin32API叩かないとイカンのがなー
684 ：デフォルトの名無しさん：2016/02/04(木) 00:49:42.50 ID:bceJfQRb: LINE風のチャット画面を作りたいんだけど、アイテムによってテンプレートを変えるってできますか？
適したコントロールはやっぱりListBoxでしょうか？
685 ：デフォルトの名無しさん：2016/02/04(木) 01:09:55.10 ID:XARWtXHF: >>683
WPFで凝った事するのに使うWin32APIって、例えばどんなの?
686 ：デフォルトの名無しさん：2016/02/04(木) 01:31:44.95 ID:gNf/It7R: 凝ったことというかいまだにPer-Monitor DPI対応させるのに
ネイティブにいってらっしゃいとか逆に凄いと思うわ

あー、WPFでもWindows CompositionとWin2D使いてえ
687 ：デフォルトの名無しさん：2016/02/04(木) 02:04:13.39 ID:Lhv4mykt: >>685
Windowのアイコンを消したい時とか
688 ：デフォルトの名無しさん：2016/02/04(木) 19:16:45.01 ID:/mGSO3bC: >>684
できる
ListBox or ItemsControl
689 ：デフォルトの名無しさん：2016/02/04(木) 21:55:42.59 ID:0aoqlSU+: >>684
アイテム(型)によってテンプレートを変えるのは、WPFの得意とするところ。
690 ：デフォルトの名無しさん：2016/02/04(木) 22:52:38.13 ID:bceJfQRb: >>688
ListBoxでやってみます

>>689
バインドしたクラスのプロパティのよって使うテンプレートを動的に変えられるんですね
ちょっと調べてみます。
691 ：デフォルトの名無しさん：2016/02/04(木) 22:54:11.94 ID:bceJfQRb: 別な質問なんですが、TabControlのHeader部分をTabControlの幅いっぱいに広げることってどうすればいいでしょうか？
タブの数が増えるごとにHeaderの幅が等分されていく感じで
692 ：デフォルトの名無しさん：2016/02/05(金) 01:42:11.84 ID:XbOWS6mh: >>691
TabControlのActualWidthをタブ数で割った値をTabItemのWidthに設定する。
693 ：デフォルトの名無しさん：2016/02/05(金) 02:23:17.64 ID:1g7NU/Mi: >>691
tabitem stretchとかでググった方が早いと思う
694 ：デフォルトの名無しさん：2016/02/05(金) 10:00:56.43 ID:gYFqnrAF: 面倒さがよく伝わるスレだ。
695 ：デフォルトの名無しさん：2016/02/05(金) 12:53:50.86 ID:3Nn1Djx6: >>690
余分な実装してるかもしれないので老婆心ながら。
型毎のDataTemplate書けばWPF側が自動的にそのテンプレートを割り当ててくれるから、アプリ側はDataTemplateを書く以上の事は必要ない。
696 ：デフォルトの名無しさん：2016/02/05(金) 19:02:40.97 ID:z6QXyU95: WPF初心者が読むべき記事や書籍ありますか？
697 ：デフォルトの名無しさん：2016/02/05(金) 19:26:16.63 ID:N9zzISA1: WPFの書籍って少ないのよね
(´・ω・｀)
698 ：デフォルトの名無しさん：2016/02/05(金) 19:54:07.65 ID:3Nn1Djx6: 記事なら、わんくまとかかなあ。
荒れそうだけどw

書籍は日本語版は少ないね。
考え方さえ慣れれば、MFCとかよりかは遥かに難しくないせいかもしれない。
699 ：デフォルトの名無しさん：2016/02/05(金) 20:25:08.63 ID:lu0JzWaI: WPFの問題は敷居の高さかね
そんなに高くはないんだけど、VB6のフォームの裏にベタ書き文化が今でも主流、かつ派遣が半数以上を占める今の開発現場で、クラスの構成をキチンと考えて設計するっていうのは難しいのかもしれない
700 ：デフォルトの名無しさん：2016/02/05(金) 20:58:41.18 ID:awzjuRq3: Windowsで業務プログラム書いてるような(雑魚)連中のニーズをキャッチアップしてないだけ
701 ：デフォルトの名無しさん：2016/02/05(金) 21:42:01.57 ID:OGjDtOe4: その雑魚連中がプログラマのほとんどなんだからしゃーない
702 ：デフォルトの名無しさん：2016/02/05(金) 22:37:34.36 ID:9/ir+N5y: Formsでカスタムコントロールを作ったりオーナードローやっていた連中は
格段に簡単になったと飛びついたものなんだがね
ただコントロールを並べていただけだとメリット無いもんな
703 ：デフォルトの名無しさん：2016/02/05(金) 22:45:34.36 ID:gYFqnrAF: WPFを採用してからのVSの評判が悪い以上、ビジネスユースで普及する見込みはない。
704 ：デフォルトの名無しさん：2016/02/05(金) 23:21:18.63 ID:81qepZ6v: >>695
例えばチャット画面だと、ListBoxにチャットのメッセージクラスのコレクションをバインドする予定です。
メッセージクラスのとあるプロパティの値によって、ListItemの位置を右寄せと左寄せで分けるようにできるかな、と思ってたんですが
そうではなくて、メッセージクラスを継承した右寄せのメッセージクラスと左寄せでのクラスをメッセージクラスのコレクションとしてListBoxにバインドして、
右寄せのメッセージクラス用のDataTemplateと左寄せのDataTemplateを記述しておけば、クラスの種類によって使われるDataTemplateが使われるってことでしょうか？
705 ：デフォルトの名無しさん：2016/02/05(金) 23:25:20.39 ID:lm1grbus: あれでもeclipseやintelijやxcodeよりマシらしいからわからん
C++の補完能力だけは突出して凄いって分かるが
706 ：デフォルトの名無しさん：2016/02/05(金) 23:40:19.17 ID:OGjDtOe4: >>704
それぐらいだったらXamlにVisualStateで描画を変更するListBoxItem定義してやればいけそうな気がする
707 ：デフォルトの名無しさん：2016/02/06(土) 01:19:20.11 ID:joaEpqO3: VisualStudioがWPFで不評なのって機能的な部分じゃなくて重くなったってだけじゃねえの
俺は2008から2012のタイミングでHDDからSSDにしちゃったから体感ではわからん
708 ：デフォルトの名無しさん：2016/02/06(土) 04:40:01.93 ID:OTYjeXYr: >>704
その考え方で良い。
但し>>706の通り、その程度ならそのやり方は大袈裟過ぎるので、左寄せ情報のプロパティとAlignment(だったかな？)をbindingするだけで良い。
(適宜Converterでも書く)

DataTemplateの切り替えは、もっと大きく描画(Controlの配置を変える等)を変えたい場合に使う。
709 ：デフォルトの名無しさん：2016/02/06(土) 04:44:09.82 ID:OTYjeXYr: VSそんなに重いか？
非同期処理がマズイっぽくて、たまに数十秒固まる事はあるがw
710 ：デフォルトの名無しさん：2016/02/06(土) 04:56:16.85 ID:9PZS47XO: 使ってる奴がこれだからなw 見えてないw
711 ：デフォルトの名無しさん：2016/02/06(土) 11:11:24.69 ID:k4UhSCgD: >>709
重いね。特にASP開発は酷い。
今はSSDの新しいPCなので速いが。
遅くて開発に支障が出ると訴えたらすぐに稟議が通ったw
712 ：デフォルトの名無しさん：2016/02/06(土) 12:57:14.82 ID:5kvIq2AE: wpf由来のボトルネックならSSDで解決できるはず無いんだが
713 ：デフォルトの名無しさん：2016/02/06(土) 13:15:40.77 ID:57BGy/1R: SSDで速くなるなら別の問題だろ
起動だけは速くなるが
714 ：デフォルトの名無しさん：2016/02/06(土) 13:16:43.63 ID:gbfzeXbU: >>712
グラフック性能だけがボトルネックだと思ってるのか・・・
715 ：デフォルトの名無しさん：2016/02/06(土) 13:22:30.22 ID:PmjXQmD8: >>714
WPF使うことで、ディスクI/O増えるの?
716 ：デフォルトの名無しさん：2016/02/06(土) 13:27:44.24 ID:gbfzeXbU: >>715
起動したらディスクI/Oしないで動作してると思ってるのか・・・・
717 ：デフォルトの名無しさん：2016/02/06(土) 13:41:28.67 ID:SJsaOsMf: うるせぇ外出て遊べよ
718 ：デフォルトの名無しさん：2016/02/06(土) 13:46:40.07 ID:57BGy/1R: 都合が悪くなると政治家みたいに話すり替えるのな
719 ：デフォルトの名無しさん：2016/02/06(土) 14:20:31.55 ID:PmjXQmD8: >>716
起動後のディスクI/Oで思いつくのはJITやDLLロード位だけど、他にある?
で、WPFだと増えるのは具体的にどこの部分?
720 ：デフォルトの名無しさん：2016/02/06(土) 14:49:05.58 ID:VXVqCJqs: 枯れ木も山のにぎわいというからもっとやれ
721 ：デフォルトの名無しさん：2016/02/06(土) 15:57:05.28 ID:57BGy/1R: 追い込み過ぎると碌な事は無いから程々に。
722 ：デフォルトの名無しさん：2016/02/06(土) 19:04:23.59 ID:DfpphHDI: WPFだからじゃなくて.netだから遅いって言えば満足するんだろ
native→.net＋WPFで遅くなったのは確実だけど
723 ：デフォルトの名無しさん：2016/02/06(土) 19:17:57.53 ID:PmjXQmD8: もしかしたら、WPFの方がWinFormsよりもJITの処理が重いとかあるのかと思ったけど、そうでもなさそうだな。
724 ：デフォルトの名無しさん：2016/02/06(土) 19:48:17.23 ID:9PZS47XO: wpfのボトルネックはおれだよ。開発が全然進まない。
725 ：デフォルトの名無しさん：2016/02/06(土) 20:13:33.63 ID:BtpsJL+V: 傷口に塩みたいで恐縮だが、.NETだろうがSSDで速くなったりはせんよ。
ディスクIO以外は。
726 ：デフォルトの名無しさん：2016/02/06(土) 22:59:21.12 ID:OeEpkpoj: WPFで重いのはレイアウトの計算だよ。
仮想化使わずに要素増やしまくると、要素間でレイアウト調整が何度も走って指数関数的に重くなる。
描画自体はものすごく速い。
727 ：デフォルトの名無しさん：2016/02/07(日) 00:44:20.94 ID:czq+z9X8: >>719
重いVSがSSDにしたら速くなったと言ってるだけで
VSがWPFだから遅いと言ってるわけじゃ無いだろ?
728 ：デフォルトの名無しさん：2016/02/07(日) 00:56:06.62 ID:QVfQg3Ot: 欠陥と言わざるを得ない。
729 ：デフォルトの名無しさん：2016/02/07(日) 08:43:39.87 ID:CTHi5OK2: >>722みたいな恥の上塗りしてるからじゃね？
730 ：デフォルトの名無しさん：2016/02/07(日) 08:56:34.93 ID:RoxT/3SR: >>727
「WPFを採用してからのVSの評判が悪い以上、ビジネスユースで普及する見込みはない。」（>>703）から始まったんだから、今更WPF関係ないとか無いわ
そもそもここはWPFスレだぞ
731 ：デフォルトの名無しさん：2016/02/07(日) 09:30:42.89 ID:czq+z9X8: >>730
VS2010以降ってそんなに評判悪いか?
今更VS2008以前のVSを使おうとは思わないよ。

ビジネスユースで普及しないのはWindows Formの機能で十分なのと
デザイン重視ならWeb化すれば事足りるからだろう。
WPFが普及しないのとVSがWPFなのとは全く関係ないよ。
732 ：デフォルトの名無しさん：2016/02/07(日) 09:55:09.70 ID:CTHi5OK2: >>703は思い込みの強い子
733 ：デフォルトの名無しさん：2016/02/07(日) 10:51:25.59 ID:czq+z9X8: VSはWPFだけど普通のWindowsアプリ過ぎてWPFを積極的に
使おうとするモチベーションに繋がらないのよね。
WPFならではの機能とかUIとか何処かにあるのか?
734 ：デフォルトの名無しさん：2016/02/07(日) 15:08:51.80 ID:oTbnOglr: VS起動したらコンポーネントの読み込み中ですみたいな表示が出ると萎える
735 ：デフォルトの名無しさん：2016/02/08(月) 12:52:42.43 ID:iMJXPrPf: リストボックスのリストアイテムを選択した時にハイライトされないようにするにはどうするのが一番手っ取り早いでしょうか？
736 ：デフォルトの名無しさん：2016/02/08(月) 13:40:40.85 ID:GixGib55: >>735
ListBoxItemのControlTemplateを弄る
737 ：デフォルトの名無しさん：2016/02/08(月) 20:35:13.51 ID:omcXALNz: >>735
out ListBox
in ItemsControl
738 ：デフォルトの名無しさん：2016/02/09(火) 17:59:53.14 ID:l5cJL/2h: 別にMVVMとかBinding活用とか除いても、デザイン変更が容易かつ柔軟ってだけで採用理由にはなり得る気はするがな
描画が重いのだけが問題だ
739 ：デフォルトの名無しさん：2016/02/09(火) 18:05:43.02 ID:Heez29w2: だからほとんどのユーザーはUI固定がいいんだって。
かっこいいデザインとか柔軟に画面が変化することを望んでいない。
740 ：デフォルトの名無しさん：2016/02/09(火) 18:53:56.24 ID:FK1/dpjR: パッケージでformsです。みたいな丸出し画面出てきたら嫌だろ
動的レイアウトはともかくとして
741 ：デフォルトの名無しさん：2016/02/09(火) 18:56:16.52 ID:Heez29w2: だからほとんどのユーザーはUIが変わるぐらいならformsでいいんだって!!!
そろそろ現実見ようぜ。
742 ：デフォルトの名無しさん：2016/02/09(火) 18:59:01.08 ID:FK1/dpjR: 前提を足すな
743 ：デフォルトの名無しさん：2016/02/09(火) 19:56:04.99 ID:ku6LpWVp: 半円とかでグラフが作りやすければなんでもいい
だからWPFは除外
744 ：デフォルトの名無しさん：2016/02/09(火) 21:21:47.32 ID:YKz8HYxB: WPFでもData Visualizationでタダでグラフ出せるやん！……と思ってたワイ
データ数多くなると重すぎで無事死亡
745 ：デフォルトの名無しさん：2016/02/09(火) 21:49:14.40 ID:3HIGQ086: 同じコストだったらWindowsFormよりも、WPFのほうが選ばれそうなんだよな
746 ：デフォルトの名無しさん：2016/02/09(火) 21:55:31.56 ID:Heez29w2: グラフ描くぐらい実際pictureboxにGDIで何も困らないなんだよ。
高機能な商用コントロール買ってもいいし。
747 ：デフォルトの名無しさん：2016/02/09(火) 22:06:58.99 ID:DH+vdKhf: ほとんどの業務アプリがフォームで十分ってのが大きい
別にボタンの形を変えたいとも思わないし
MVVMとか全く必要とされてないし
ガイドラインに沿って真剣に崇高にMVVMで設計すると
クラスが増えて逆にコストがかかりそうと考えるだろう

ボタンが押されたらハンドラが呼ばれて、そこにアクションを書く
これほどわかりやすい物は無いからね
フォームで十分ってなる
748 ：デフォルトの名無しさん：2016/02/09(火) 23:33:34.58 ID:MU1eNc83: ボタンが押されたらハンドラが呼ばれて、そこにアクションを書く
これをWPFでやってもいいんだよ？

個人的には、Formsはデザイナがイマイチ
XAMLであらよっと書いてしまう方が速い
749 ：デフォルトの名無しさん：2016/02/10(水) 10:12:34.04 ID:5Sg0dwj9: >>740
すまんのう(ーー;
750 ：デフォルトの名無しさん：2016/02/10(水) 10:21:50.79 ID:WiPRizEA: WPFで書かれたPaintDotNetみたいなお絵かきソフト、できればソースが公開されてるもの、ありませんか？
751 ：デフォルトの名無しさん：2016/02/10(水) 12:19:03.43 ID:5Sg0dwj9: >>750
CodePlexかGitHubで探せば？
752 ：デフォルトの名無しさん：2016/02/10(水) 21:43:50.83 ID:9+6izXko: ItemsControlのItemの間にセパレーターを入れたいのですが、どうすればいいでしょうか？
ItemのDataTemplateにセパレーターを含めると上か下に余分なセパレーターが表示されて困っています。
753 ：デフォルトの名無しさん：2016/02/10(水) 22:32:16.75 ID:nrzNetuv: ItemContainerStyleをごにょごにょ。
754 ：デフォルトの名無しさん：2016/02/10(水) 22:40:25.01 ID:cPl12En4: http://stackoverflow.com/questions/7767097/use-different-template-for-last-item-in-a-wpf-itemscontrol
たかがこれだけのことに本当にこんなことしなけりゃならんのか？
設計した奴は衒学趣味でもあんのか？
流行るわけねえよこんなゴミ
755 ：デフォルトの名無しさん：2016/02/10(水) 22:48:19.31 ID:1BDU6btm: AlternationIndexとAlternationCountを使う方がよい
それでもあまり綺麗とはいえないが
756 ：デフォルトの名無しさん：2016/02/10(水) 23:13:18.89 ID:1BDU6btm: AlternationIndexを使った場合に具体的にどこが不満かと言うと
Triggerを使うのでFirst(あるいはLast)Itemかどうかを判断するためだけのConverterを書かされる

俺なら、アイテム間に線引くの止めますね
もっと言えば、WPFで作るの止めますね
757 ：デフォルトの名無しさん：2016/02/10(水) 23:19:19.53 ID:ibrp55mJ: paddingをマイナスにして隠す
758 ：デフォルトの名無しさん：2016/02/11(木) 08:18:31.23 ID:lyVDOi9V: >>754
List=ItemsControlの思い込みがダメ。
単純にTextBlockにConverterでOK。
759 ：デフォルトの名無しさん：2016/02/11(木) 08:23:47.56 ID:lyVDOi9V: 少し考えただけだけど、>>757が一番簡単な気もする。

探せば、そんなようなコントロールがあるかもね。
760 ：デフォルトの名無しさん：2016/02/11(木) 10:41:30.87 ID:TqQLMkv7: ウィンドウの左側にツリーが表示されて，その項目をクリックすると，
右側に指定された設定パネルが表示される仕組み，どうやって作るのかな？
VisualStudioのオプションウィンドウみたいなやつ．
XAMLレベルでできるんじゃないかと思ってはいるものの，検討がつかない．

一応，代替手法として，タブを使って耳を左側に表示はできるので，
作るのが大変そうなら別にやらなくてもいいのだが．
761 ：デフォルトの名無しさん：2016/02/11(木) 10:58:15.31 ID:tm4oqrS+: 右側の中身をカスタムコントロールとかにして、
ツリーのアクションとかで右のcontentを切り替えりゃいいんじゃね
テキトーだが
762 ：デフォルトの名無しさん：2016/02/11(木) 11:46:59.52 ID:3WugONV8: MVVMなら左側のSelectedItemを右側にバインドするだけだな。
763 ：デフォルトの名無しさん：2016/02/11(木) 11:54:04.60 ID:M5CwB86R: >>760
NavigationService使って作ったら楽にできるんじゃねーのかな
機能ごとページを書けるからごちゃごちゃしないだろうし

ここらに解説有ったから貼っとくよ
http://gushwell.ldblog.jp/archives/52335648.html
764 ：デフォルトの名無しさん：2016/02/11(木) 20:08:26.64 ID:6rGpnoDF: MVVMの名前出すと荒れそうなんでw

左側のツリーの項目毎のモデルはあるはずだから、それ用のDataTemplateを書く。
右側にContentPresenterでも置いて、ツリーのSelectedItemにBinding。
これだけ。
切り替えるコードを書くまでもない。
超楽チン。
765 ：デフォルトの名無しさん：2016/02/11(木) 20:17:28.33 ID:6rGpnoDF: ItemsControlのItem間だけにセパレータ置くのは、ググると色々出てくるのな。
まあ、最初か最後の区別するコードは、何やっても書かないかん訳で、それくらいは手間隙惜しむなよとは思う。
766 ：デフォルトの名無しさん：2016/02/11(木) 20:48:53.42 ID:LNzJYiWm: 何もかもXAMLにロジック入れたくないアレルギーのせい。
767 ：デフォルトの名無しさん：2016/02/11(木) 21:34:45.71 ID:TqQLMkv7: みんなの意見を参考に，いろいろ調べまくって，リストボックスで項目名を選択したら，
指定のxamlファイルが開くようにはできた．XAMLしか書いてない．
ツリービューの方はできそうでできてない．

<Grid>
<Grid.Resources>
<XmlDataProvider x:Key="Pages" XPath="Pages">
<x:XData>
<Pages xmlns="">
<Page Title="C# 入門" Url ="Page1.xaml" />
<Page Title="信号処理" Url ="Page2.xaml" />
<Page Title="力学" Url ="Page1.xaml" />
</Pages>
</x:XData>
</XmlDataProvider>
</Grid.Resources>

<ListBox x:Name="listBox" ItemsSource="{Binding XPath=/Pages/Page, Source={StaticResource Pages}}" IsSynchronizedWithCurrentItem="True" DisplayMemberPath="@Title" SelectedValuePath="@Url" />
<Frame x:Name="frame1" Content="Frame" Source="{Binding SelectedValue, ElementName=listBox}" NavigationUIVisibility="Hidden"/>
</Grid>
768 ：デフォルトの名無しさん：2016/02/11(木) 21:50:06.24 ID:Hglx3TLc: 既にデスマーチですな。
769 ：デフォルトの名無しさん：2016/02/12(金) 07:48:59.33 ID:00n43yFC: >>767
こんな書き方が出来るんだね。
勉強になる。
770 ：デフォルトの名無しさん：2016/02/13(土) 01:40:26.71 ID:/4XWxVNh: コピーができるTextBlockってやっぱりないの？
771 ：デフォルトの名無しさん：2016/02/13(土) 02:05:02.60 ID:TbN3EZfR: ねーんじゃね。１つ２つならtextboxでreadonlyとistabstopと外観でするしか
772 ：デフォルトの名無しさん：2016/02/13(土) 19:52:57.97 ID:FAqLoKs2: 久しぶりにWPFいじったけどnumericupdownなかったんだっけ…
他もいらいらさせられてリタイア
773 ：デフォルトの名無しさん：2016/02/13(土) 20:33:45.68 ID:IDGCJ7TJ: Extended WPF Toolkit入れれば似たようなのはあるけど、
そういうのに頼らなくても良いくらい、Windowsフォーム並の数のコントロールを提供してほしいね。
774 ：デフォルトの名無しさん：2016/02/13(土) 21:35:22.89 ID:PUT0GJ5R: 数年ぶりにＷＰＦいじったけど、かなり早くなってる？
ＰＣの性能があがったから勘違い？
どっちでもいいけどオラわくわくしてきた
775 ：デフォルトの名無しさん：2016/02/14(日) 00:23:40.70 ID:l8k1FRK9: 錯覚って怖いなｗ
776 ：デフォルトの名無しさん：2016/02/14(日) 00:47:59.41 ID:mwiD0ozs: WPFが早くなったかどうか確かめるのは簡単で
VSはWPFで書かれているから、それで大体の速度はわかる
VS2013と2015でもっさり感は変わらないので
多分高速化していないと思われ
WPF化以前のVS2008の軽快さが懐かしい
777 ：デフォルトの名無しさん：2016/02/14(日) 02:02:10.49 ID:Nk5+E3HV: 同じPCに2005~2013まで入れて使ってたけど
別に2005,2008が2013より軽いとかそんなことないよ全然。
778 ：デフォルトの名無しさん：2016/02/14(日) 02:30:37.91 ID:UhMFSh8J: 仮想PCに入れると顕著に現れるその重さ。
779 ：デフォルトの名無しさん：2016/02/14(日) 02:44:55.49 ID:jnOIJnE2: >>778
仮想はCPUパワーをネイティヴで使えるけどGPUがそのまま使えないからな
MS的にはWPFのほうが作りやすいのか？デモ的なのか
そのうちエレクトロン的にASP.NET MVCとIIS Expressの組み合わせになったりして
780 ：デフォルトの名無しさん：2016/02/14(日) 03:08:44.40 ID:SS1KUmSL: MS系開発ってうんこみたいのばっかり

mmp
lud20160214075744

TOPへ TOPへ　

		ブックマークへ

03:52:17 up 65 days, 4:51, 0 users, load average: 9.70, 10.31, 10.15

in 0.016257047653198 sec @0.016257047653198@0b7 on 062116

WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part19 [転載禁止]©2ch.net ->画像>6枚