C#, C♯, C＃相談室 Part91

C#, C♯, C＃相談室 P ..

41:デフォルトの名無しさん
16/11/07 23:46:06.46 d19P1q1E.net
WPFはせっかくがんばって色々できる土台を作ったのに、完成度を上げ切れてないのが何とも勿体ない。
ReactiveProperty(MS製のオープンソース)とか標準で入っていればずいぶん作りやすくなるのに。
標準のコントロールも数が足りないね。
とは言え、WindowsFormsよりもWPFの方が楽な場合もあるから、結局両方使う。

42:デフォルトの名無しさん
16/11/08 00:28:14.64 mUYwed62.net
WPFってWinFormプロジェクトと混在して使えるの？

43:デフォルトの名無しさん
16/11/08 00:31:06.09 mUYwed62.net
>40
完成度のもんだいだろうか？　そもそも根本的なところで間違ってるような気がする。
何が間違っているのかうまく言えないが、、、W

44:デフォルトの名無しさん
16/11/08 00:41:11.17 mUYwed62.net
MSのドキュメントって最近は多少ましになっては来ている部分も少しだけあるけど
ほとんどが駄目だとおもう。頭の悪い奴の書いた文章そのものって感じがする。
簡単なことを難しく書いていて要領を得ない。ワザとやってるのかなと思って
いたがそうでもないらしい。　こんなドキュメントを書くようではスッキリした
まともな言語の開発はできないと思う。
　でもC#は奇跡的に素晴らしいと思う。この素晴らしさはMS的ではないな。WPFは
MS的だと思う。

45:デフォルトの名無しさん
16/11/08 00:51:04.50 360M0HJP.net
>>41
WPFにWindowsFormsHostコントロールってのがあるので、それを利用してFormsのコントロールを使える。
その逆はやったことないけど、ElementHostコントロールを利用するらしい。

46:デフォルトの名無しさん
16/11/08 01:21:27.86 Iqb/ffmt.net
>>26
Formsの何がダメかというと意識の低い雑魚プログラマでも手が出せるところだろうな
雑魚が書くとすぐにレイヤがぐちゃぐちゃに混ざり合い重複したコードが際限なく増えていきオブジェクトから手続きの時代にタイムスリップする
油断して監視を緩めるとあっという間に手に負えなくなる
WPFは雑魚は切り捨てられてるからそういったリスクが少ない
MVVMという共通の概念を身に付けた意識の高い人材が集まるから自然とコーディングスタイルが統制されて読みやすい高品質なコードが出来る

47:デフォルトの名無しさん
16/11/08 02:27:54.02 KFsAZFmi.net
>>45
WPFのコードを読みやすい思ったことは一度もないわ。
しかし、凄い倒錯だねw
Windows Formの問題はダメな奴でもそれなりに（可読性のないコードを）書けてしまうことだというが、
それを言うならWPFの問題はまともなプログラマが書いても決して可読的にならないことだろう。

48:デフォルトの名無しさん
16/11/08 03:24:51.90 iu8f14dF.net
可読性が悪いっていってるのは XAML のこと？
それともバインドしてるプロパティがどれなのかわからないみたいなこと？
前者ならもうどうしようもないけど、
後者ならWindows Formでも同じ気がするし、
バインドとかCommandとか使わずにイベントドリブンで作る方法もあるよ。

49:デフォルトの名無しさん
16/11/08 03:48:44.45 mUYwed62.net
>47
どっちがダメかといわれても答えようがないが、ダメなものを平気で追加している
と、少しだけはいいものがあったにしてもダメになるよね。
いいものなら直観的にシンプルに説明ができると思う。
C#の属性拡張なんかも、その点ではかなり危ない。でも本体がしっかりしているので
あまり汚れが目立たない。
WPFは最初からダメでしょ。そもそも取り付けないし見通しも見えない。１日ほど
弄ってみたことがあるが、全然わからんかった。何がいいのかさっぱりわからん。
直観的に説明できないようなものって間違ってると思うよ。
こういう場合二つのアプローチがあると思う。
１．訓練してこれに慣れるという方法
２．何がダメなのか何が問題なのか発見するという方法
後者を採用する人にはこれはある意味チャンスだと思う。まあでもこれを使いこなせる
ってことは「頭いい」って証明にはなると思うから、１．のアプローチも間違い
じゃない。W

50:デフォルトの名無しさん
16/11/08 04:02:41.99 VojG/etj.net
>>43
英語を読んでる？
日本語版は機械翻訳だよ

51:デフォルトの名無しさん
16/11/08 05:54:50.91 360M0HJP.net
>>48
1日しか触ってなくてほとんど何も理解もしてないのにダメ出しってのも何だかな。
従来と仕組みが違う部分が多いから、従来の(WindowsGUIプログラムの)経験からの直観は働きにくい。
学習コストがかかるのもデメリットではあるけどね。

52:デフォルトの名無しさん
16/11/08 07:31:09.86 TXhVVjP1.net
雑魚排除といえば
VBを残し続ける理由が分からない
VB作る人的リソースを
XAML強化とかに回せば良いのに

53:デフォルトの名無しさん
16/11/08 07:36:07.95 TXhVVjP1.net
WPFはFormアプリが
健在だから使う機会がない
MSの下位互換の精神は悪いと
言わないけど、もう良いんじゃねって
技術が延々と残ってるから
嫌になる

54:デフォルトの名無しさん
16/11/08 07:48:59.11 uO4YTQEs.net
俺は最初からWPFを使ってるのでWindowsフォームの利点がわからん。
あらゆる点でWPFの劣化版のように思えるのだが。

55:デフォルトの名無しさん
16/11/08 07:54:17.11 Iqb/ffmt.net
>>48
こういう人をお断りできるだけでもすごいメリットだよな
WPF程度の難易度のフレームワークを1日で諦めるとかちょっとな
昔は多かったオブジェクト指向はよくわからないから悪もの理論の年配と同じ臭いを感じる

56:デフォルトの名無しさん
16/11/08 08:01:23.60 6Cpjtpfi.net
>>40
>ReactiveProperty(MS製のオープンソース)
Prismとごっちゃにしないでね。
ただアレは便利だわ

57:デフォルトの名無しさん
16/11/08 08:10:26.28 6Cpjtpfi.net
Formsで出来るレベルのことだけでいいなら、そりゃFormsのほうが楽かもしれんね
でも、コントロールの外観をいじりたいとかって話になると、wpfのほうがずっと楽だろ
Formsでアニメーショなどどうやってヤるんだよ

58:デフォルトの名無しさん
16/11/08 09:36:53.50 +DS6ozoh.net
だからそういう用途じゃなきゃFormsだし
そういう用途にしてもUWPに移行するって話だろ

59:デフォルトの名無しさん
16/11/08 10:24:37.04 h2p8PH96.net
>>53
例えば、Formの利点というよりWPFの欠点だけどグラフィックのパフォーマンスだね。
GDI+も登場時散々遅いと叩かれたけどWPFはその何十倍も遅い。
ググると出てくると思うけど、あまりに遅くて、2Dの折れ線グラフのような単純なものでも
データ数が多いと全く使い物にならない。
俺自身パフォーマンスの問題をどう工夫しても解決できなかったので結局GDI+で書き直すはめになった

60:デフォルトの名無しさん
16/11/08 11:20:31.78 mUYwed62.net
>50
XAML
<TextBox
Width = "100" FontSize = "30" Text = "テスト"
Background = "White" Foreground = "Blue" />
C#
textbox1.Width = 100;
textbox1.FontSize = 30;
textbox1.Background = Colors.White;
textbox1.Foreground = Colors.Blue;
textbox1.Text = "テスト";
文字少なくてよさげだけど、肝心のこの部分が隠れる。
TextBox textbox1 = new TextBox();
大事なところを隠蔽されるのはダメだよ。
プロパティを並べるのに＜＞で囲む必要なんてどこにあるんだよ。
という感じ。文書として保存するときなら＜＞つけたらいいではない？
でもエディットするときにこんなもんは不要だ。

61:デフォルトの名無しさん
16/11/08 11:31:34.08 mUYwed62.net
<TextBox
Width = "100"
FontSize = "30"
Text = "テスト"
Background = "White"
Foreground = "Blue"
/>
文書保存するときはこれは別にいいと思うけど、もともと簡単に打ち込みできるよう
になってるものを、テキストで打ち込む理由はないな。

62:デフォルトの名無しさん
16/11/08 11:43:12.95 mUYwed62.net
>47
XAMLはNetをXMLで表現するタグだけのことだろ。
それは別にそれでいいんでないか？整理できるし。
問題はWPFっていう糞のIDEだな。見通しがきかない保存文書構造のXMLを使って
なんでプログラム組まなきゃなんないのってこと。本末転倒だろ。W

63:デフォルトの名無しさん
16/11/08 12:00:35.75 mUYwed62.net
＞コントロールの外観をいじりたいとかって話になると、wpfのほうがずっと楽だろ
＞Formsでアニメーショなどどうやってヤるんだよ
　楽なのは抽象度が高くなっていて、逆に言えば細かい処理はできないってことだね。
FormでできないことがWPFでできるわけじゃなくて、それなりのコントロールを用意して
楽にしているだけ。楽なコントロールが楽になってるだけ。そういうのを適宜使うって
のはありだと思うよ。アニメーションとか、、、、アニメーションとかほかにどんなもの
がある？　でも.netになくてWPFだけにあるものなんてある？

64:デフォルトの名無しさん
16/11/08 12:12:18.45 mUYwed62.net
xmlns="URLﾘﾝｸ(schemas.microsoft.com)
xmlns:x="URLﾘﾝｸ(schemas.microsoft.com)
エディターにロードした段階でこんなタグは不要だろ。なんでこんなのがいちいち
画面を占有しているの？　バカっぽいと思わん。
これがなければ余分に２行ソースが見える。W

65:デフォルトの名無しさん
16/11/08 12:47:02.22 unEOfTV3.net
>>59
なんでXAMLにすり替えてんだよじじい

66:デフォルトの名無しさん
16/11/08 14:50:51.38 CGI+nyHh.net
男だったのか

67:デフォルトの名無しさん
16/11/08 15:14:04.09 EaH/m5NR.net
GUIフレームワークなんて何使っても大差ない
根本的な設計がしっかりしてれば楽
でなければ何やっても苦痛

68:デフォルトの名無しさん
16/11/08 16:42:41.52 TdC6P0sc.net
newも、ソースの見通しとも、xmlnsについてもWinFormsではデザイナが自動生成するコードだからほとんど見ないし、自動生成コードよりはXamlのほうが優れてるだろ
WPFの問題はバインディングとかMVVMとかがなかなか難しいし、情報資産が少ないことにある気がする
少なくとも、外観やコントロールの機能いじったり、バインディングを活用するなら悪くはない

69:デフォルトの名無しさん
16/11/08 17:07:35.31 uO4YTQEs.net
>>58
そうなのか。
本当にWPFが遅いのかは限界までチューニングしなきゃわからんとは思うが、
少なくとも通常のやり方ではWindowsフォームのほうが速いというわけだな。
WPFでは勝手に画像がスケーリングされたり、
アンチエイリアシングされたりするのでそういったのを
徹底的に無効化しなきゃ速くならんからな。
画像を綺麗に見せるためなのか知らんが、
こういったマクロソフトの俺様仕様は勘弁してほしいところだわ。
>>59
そんなにXAMLが嫌いならXAMLを使わなきゃいいだろ。
そもそもXAMLはWPFとは何の関係もない。
XAMLを使わなくてもWPFプログラミングなどいくらでもできる。

70:デフォルトの名無しさん
16/11/08 18:00:32.99 mUYwed62.net
＞６８
えっ、そうなんだ。チュートリアルはほぼxamlの説明だけだよ。W

71:デフォルトの名無しさん
16/11/08 18:03:46.28 mUYwed62.net
一時期XMLが流行った時があって猫も杓子もXML状態になったよね。そのあと全部
失敗してXAMLはしぶとく残ってるということではないのか？

72:デフォルトの名無しさん
16/11/08 18:52:03.52 WSlpNxFl.net
もうザマリンでAndorido準拠の
プログラム作れば良いよ
WindowsPhoneのシェア0.3%で
WPFの先も無さそうだし

73:デフォルトの名無しさん
16/11/08 18:56:36.28 WSlpNxFl.net
FormアプリとVBは
Windows7までにしておけば良いのに
共に役目は終えたし
MSはリソースを少し集中しようよ
モバイルじゃシェア失ってるんだし

74:デフォルトの名無しさん
16/11/08 20:25:06.49 UoXgnYKD.net
Win32API時代から自分で描画するコントロールを作っていくのが好きすぎて未だにやめられない

75:デフォルトの名無しさん
16/11/08 20:40:02.61 RPJf2WNu.net
WinFormは趣味グラマにとってぬるま湯で居心地がいいｗ
IDEのおかげで下手なスクリプトより楽だし

76:デフォルトの名無しさん
16/11/08 20:51:54.08 360M0HJP.net
>>55
すまん。完全にごっちゃになってた。
>>59
その例だとXAMLにx:Name="textBox1"が抜けてるぞ。
XAMLでの<TextBox>タグの宣言こそが、TextBox textbox1 = new TextBox();
に相当するってだけで、別に隠しちゃいない。

77:デフォルトの名無しさん
16/11/08 20:58:12.04 RPJf2WNu.net
ついでに流れに乗っておくと
>>58
WPFはGDI+（WinForm)よりもグラフィック関連は速くなるものだと思っていた
WinFormは扱うデータサイズが大きくなると消費するメモリサイズが飛躍的に増えるんで、グラフィック関連は扱うのにあまり適していないんだよな

78:デフォルトの名無しさん
16/11/08 21:15:33.89 360M0HJP.net
>>76
あるポイント数を超えるとまったく実用じゃないくらい遅くなるね。
ポイント数が多くてスピードが要求される場合は、DirectXを使って高速描画出来る有償のコントロールを買うしか無さそう。
数年前の資料だけど、各種チャートコントロールの性能比較
WPF Charting Performance Comparisons (the Battle Continues)
URLﾘﾝｸ(blog.scottlogic.com)

79:デフォルトの名無しさん
16/11/08 23:17:39.44 6Cpjtpfi.net
ポイント数が多くてスピードが要求されるなら、データを間引いたほうが現実的じゃなかろうか？
データ視覚化なら２、３００もアレば十分だろ

80:デフォルトの名無しさん
16/11/08 23:28:48.20 o3gm2pi/.net
そんな高度なことができるわけないだろ

81:デフォルトの名無しさん
16/11/08 23:52:00.16 6Cpjtpfi.net
>>79
もうちょっと頑張れ

82:デフォルトの名無しさん
16/11/09 00:13:40.23 HQuuA4JA.net
>>49
他のベンダーのヘルプとか見たことないんだろ
MS なんてかなりまともな方だと思う

83:デフォルトの名無しさん
16/11/09 01:04:00.05 SotHgA9V.net
>>78
系列が少なければね。

84:デフォルトの名無しさん
16/11/09 01:09:36.44 SotHgA9V.net
>>62
知らないのに当てずっぽうで書いてるのが良く分かるな

85:デフォルトの名無しさん
16/11/09 02:23:18.79 pYqjQFAT.net
>77
イケてるやないか。　でもデータバインディングやったらボロボロ。W

86:デフォルトの名無しさん
16/11/09 02:57:40.95 pYqjQFAT.net
>に相当するってだけで、別に隠しちゃいない。
隠すつもりがなくても視認性が悪いから隠れるんだな。これが、、
WPFの肝は
１．UI部分は XAML で記述
２．実行コードは C# または VB
３．グラフィックス描画は DirectX
４．データドリブン的なものをデータバインディングでやる
１．と４．が手抜きでいい加減だから全然だめ。
１が駄目だから２を書こうにもどう書いたらいいのかわからないというジレンマ
４がダメだから遅いし使いにくいし使い物にならないしトータル的には失望を加速
している。
料理の材料はまあこんなものでいいというか素材は素晴らしい。しかし集めて料理
するんならもっと一つ一つを丁寧に作りこまなくてはだめだろ。これじゃ味の
バランスが悪くて料理になってない。もうひと手間かけるのができないんだよな。
最後までやりきることができない。思い付きと能書きは立派。W

87:デフォルトの名無しさん
16/11/09 03:24:51.72 pYqjQFAT.net
<Window x:Class="SliderTest.Window1"
xmlns="URLﾘﾝｸ(schemas.microsoft.com)
xmlns:x="URLﾘﾝｸ(schemas.microsoft.com)
Title="Window1" Height="300" Width="300" Background="LightBlue">
<Grid>
<TextBox Height="24" HorizontalAlignment="Left" Margin="30,19,0,0"
Name="textBox1" VerticalAlignment="Top" Width="72"
Text="{Binding ElementName=slider1, Path=Value}"/>
<Slider Height="22" Margin="28,64,20,0" Name="slider1" VerticalAlignment="Top" />
</Grid>
</Window>
この書き方は糞
Text="{Binding ElementName=slider1, Path=Value}"/>
こうなるのが正解。
Text="{Binding slider1.Value}"/>

88:デフォルトの名無しさん
16/11/09 04:07:40.94 pYqjQFAT.net
ファンクションキーのイベント発生に見れるセンスのなさ
こんな書き方はどんだけ糞か？　ネーミングのセンスがまるでない。
PreviewKeyDown="Window_PreviewKeyDown"
これがセンスのいいなまえ
FunctionKey = "KeyDown"
もしくは
KeyDown="FunctionKey"
KeyDown="F1"
など

89:デフォルトの名無しさん
16/11/09 04:26:59.85 pYqjQFAT.net
プロパティ値の継承に見る手抜き
　プロパティ値が割り当てられていない子要素がある場合、プロパティ値の設定がある
最も近い親要素の値を割り当てる。W　
まあこういう問題が発生するのも、手抜きが手抜きを生むことの良い例だ。ボタンコン
トロールひとつを表すのに手近な要素をかき集めて作りあげるという手抜きをしたこと
で、イベントがうまく取れないという問題が発生した。そこでイベントルーティング
という新たな手抜き概念を導出してしかもプロパティ継承という誤魔化しまでしなくて
はならなくなった。
　トンネル、バブル、ダイレクト　イベント一つにこんだけ複雑なことをする羽目にな
ったのも、最初に行ったわずかな手抜きが原因なのだ。

90:デフォルトの名無しさん
16/11/09 04:29:27.99 9orsc4MQ.net
>>86
>>87
業務で使う場合はViewとViewModelをきっちり分けるよ
なのでバインディング式は下記のように
<TextBox Text={Binding ResultMessage} />
シンプルになる。
View内の他の要素の値をバインドするなんて
滅多にないから（デバッグ時くらい？）、{Binding ElementName=slider1, Path=Value}
みたいな冗長な書き方はいいと思う。
装飾系も普通はResourceDictionaryにまとめる。TextBoxタグ内にゴテゴテ書いたりしない
<Window.Resources>
　<ResourceDictionary>
　　<Style TargetType="TextBox">
　　　<Setter Property="VerticalContentAlignment" Value="Center" />
　　　<Setter Property="HorizontalAlignment" Value="Left" />
　　　<Setter Property="Foreground" Value="{StaticResource GlobalForeground}" />
　　</Style>
　</ResourceDictionary>
</Window.Resources>
キー押下時のイベント発生もViewはCommandをViewModelに発行するだけだね
<Window.InputBindings>
　<KeyBinding Gesture="Ctrl+T" Command="{Binding MenuOpenCommand}" />
</Window.InputBindings>
イベント発生時の処理内容をxaml.csに記述したりはしない

91:デフォルトの名無しさん
16/11/09 04:36:52.64 pYqjQFAT.net
データバインディングに見る手抜き
「WPF のデータバインディングはこれだけで 1 冊の本が書けるほど面倒です。」という
関係者。たったこれだけで関係者が本を書いて１０年は食える飯のタネになる。W
WPFにおけるデータバインディングの重要性と可能性はこの限りにおいては非常に成功
している。テーマとしては食いつきがいい。「これさえマスターすれば、あとは
データを流し込むだけで自動的に表示してくれる」
魅力的なのだ。
食いつきがよくて、複雑怪奇な場合には関係者は情報を小出しにすればかなり長期に
わたってよい飯の種になる。

92:デフォルトの名無しさん
16/11/09 04:37:26.02 pYqjQFAT.net
さあ寝よう。おやすみ

93:デフォルトの名無しさん
16/11/09 07:27:40.65 ccPtaul1.net
>>91
そこら辺が問題だと思うのなら、全て解決したUWPに移行したら良いんじゃないのかな？
x:Bindで事前バインディングで厳密に型チェックヤるし、イベントバインディングも出来るからな
つか、アンタの言い分はイソップ童話の酸っぱいブドウそのものです

94:デフォルトの名無しさん
16/11/09 07:54:15.04 TlbuxVnv.net
個人的にUWPに偏見を抱いている理由はOneNoteが糞なせい
OneNoteの糞さはUWP無関係だと思うが、自分の観測範囲にUWPの実用サンプルがそれしかないので
どうしても印象が引っ張られる

95:デフォルトの名無しさん
16/11/09 09:17:12.31 KnEUpDo2.net
XAMLに親を……

96:デフォルトの名無しさん
16/11/09 09:17:36.57 SotHgA9V.net
>>87
KeyDownってイベントは別にあるぞ
>>88
もはや言いがかりのレベルだな

97:デフォルトの名無しさん
16/11/09 12:09:48.16 pYqjQFAT.net
>89
どんな糞言語でも本質をよく見極めてセンス良く使う人はいるものだよ。
しかしそこに到達するまでにどんだけ時間がかかるというのだ。俺なんかわけわからん
から右往左往するばかりだよ。
せめてBlendをまともに作ってくれれば、それなりにUIの問題は解決するのにな。
Blendも糞だろ。W　最近のは使ってないからわからんが、、、

98:デフォルトの名無しさん
16/11/09 12:10:37.11 pYqjQFAT.net
＞そこら辺が問題だと思うのなら、全て解決したUWPに移行したら良いんじゃないのかな？
＞x:Bindで事前バインディングで厳密に型チェックヤるし、イベントバインディングも出来るからな
今度はUWPかよ。小出しにするなー。つまりWPFは糞だったと認めるんだな。W

99:デフォルトの名無しさん
16/11/09 12:12:21.25 C35LXred.net
UWPは互換性取るために使えない機能が多すぎてFormやWPFと比較する気にもなれない

100:デフォルトの名無しさん
16/11/09 13:18:01.59 imHVERPt.net
で？。W

101:デフォルトの名無しさん
16/11/09 13:24:22.96 13V/HCY3.net
またストアアプリみたいにいつ梯子外されるかわからないUWPに手を出す人は
よっぽどお勉強好きなんだろうなw
仕事ならしょうがないけど自分の時間使って勉強する気にはなれんわ

102:デフォルトの名無しさん
16/11/09 13:44:46.30 U6OuotlL.net
WPFに手だしちゃった人ならいけるでしょ

103:デフォルトの名無しさん
16/11/09 16:05:04.67 L45XBX69.net
>>87
コードビハインドにイベント書くことはおすすめされないし、そもそもPreviewKeyDownってFunctionキーのイベントを受け取るためのイベントじゃないぞ？
WinFormsにも同じ名前のイベントあったじゃん
WPF以前の根本的な能力がかけてるんじゃね？

104:デフォルトの名無しさん
16/11/09 19:12:41.31 UPD5ANvk.net
UWPって多重起動できるんですか？

105:デフォルトの名無しさん
16/11/09 19:23:20.90 c1gJ8Ir2.net
Windows１０のPCは買ったけど、予備にした古いPCで動かす事を考えたらUWPは使いたくないな
まだ動く７とXPのPCがあるからな

106:デフォルトの名無しさん
16/11/09 20:02:19.12 xK7OwzcU.net
WPFやってないんだが、そもそもXAMLは人間が見る必要のあるものなのか？
VSのデザイナやBlendがダメすぎるのか？
フォームでさえ、.Designerの中身なんてほぼ見る事ないのに
人間が生のXAML見たり編集したりしないとダメならそら普及しないなと思うが

107:デフォルトの名無しさん
16/11/09 20:09:14.52 y+VOBp5j.net
XAMLはなにもかもXML（？）で記述できるようにしようとして失敗してる感じ
レイアウトだけにしとけばいいのに

108:デフォルトの名無しさん
16/11/09 20:09:22.06 knOh/4SR.net
データバインディングが遅いとかいって大量データをなんの工夫もなく描画する画面を引き合いに出す人ってたまにいるけどあれって悪意があってやってるの？

109:デフォルトの名無しさん
16/11/09 21:24:36.59 WmFTPhhE.net
普通、設定ファイルを、人が直接いじったりしない
Godot(ゴドー)などのゲームエンジンでは、IDEの右側にある、
インスペクタービューで、プロパティなど設定する
オブジェクト同士の衝突判定・イベント通知なども、同じ

110:デフォルトの名無しさん
16/11/09 21:25:12.33 TlbuxVnv.net
どこぞのフレームワークで「人間にXMLを書かせるなんて虐待です」って書いてるのがあったけど
ほんとその通り

111:デフォルトの名無しさん
16/11/09 23:41:49.58 7n7DDFeG.net
つうかここってC#＋Windowsフォームしかやってないやつばかりなの？
XAMLはそもそもWPFだけのもんじゃないんだが。
Silverlightにも使われていたしUWPにも使われてる。
そしてC#だけじゃなくVBにも使われてる。
つまり、言語や�

112:Nラスライブラリなどから分離できるものは分離しようっつーのがXAMLでしょ。 C#/VBとXAMLの関係はJavaScriptとHTMLの関係と似てる。 XAMLを批判してる奴ってほんとにXAMLを理解してんの？

113:デフォルトの名無しさん
16/11/10 00:11:40.20 TlbdJV8L.net
1日で挫折したのにここまで批判できる >>48 はすごい人

114:デフォルトの名無しさん
16/11/10 00:22:28.24 4pFcdHJl.net
JavaScriptとHTMLではなくJavaScriptとJSONの方が近いな
XAMLはただのシリアライズフォーマットの１つでしかない
WPFと関係ない普通のオブジェクトもXAMLにシリアライズできる
そんでXAMLはJSONと違って型とアセンブリの情報を持つ
UIデザインを宣言する手段として考えると書きにくいXAML形式よりシンプルでインテリセンスもよく働くC#コードの方が優れているのは確かだろう
しかしそうではなく可視性と可搬性のある普遍的なシリアライズフォーマットとして考えるとXAMLがXMLを採用したのは自然な帰結と言える
可視性のためにはテキストでなければならない
可搬性と普遍性では対抗馬としてJSONがあるがJSONはシンプルすぎて表現力がちょっと物足りない
となるとXMLは妥当な選択と言っていい
新しい時代に乗り遅れてXMLにしたわけでもないし虐待目的でXMLにしたわけでもない
XAMLの目的に合致するフォーマットではXMLがベストだったというだけの話なんだ

115:デフォルトの名無しさん
16/11/10 00:29:57.49 ApowNrKS.net
wpf使うならelectronでいいや感ある

116:デフォルトの名無しさん
16/11/10 01:16:39.44 Co+DcSGG.net
AndroidStudio使っててもXMLは出来るだけいじりたくないｗ

117:デフォルトの名無しさん
16/11/10 01:52:09.10 aHkFnxeg.net
＞１０２
ん？
それは考え方に矛盾があるだろ。UIを切り離すのが目的�

118:ﾈら、切り口がシンプルで綺麗なほうがいい。例えばスクロールバーと連動して値を表示する場合なんてUI内でまとめて片づけてしまったほうがいい。ほしいの値だけで、処理側からしたらくだらないイベントなんて見えないほうがいい。そっちでまとめてやってほしい。

119:デフォルトの名無しさん
16/11/10 01:52:28.80 aHkFnxeg.net
>XAMLを批判してる奴ってほんとにXAMLを理解してんの？
理解できないなから文句を言ってるんだよ。機械が簡単に理解できるからって
人間にそれを押しつけるのは間違い。
XAMLってのは単なるテキスト文書じゃない。プログラム全体から複雑なUIを切り離して
表現するという目的がある。複雑なUIは手打ちで入力するようなものじゃない。
UI＝｛動作、表現、パラメータ、、、、｝＋窓口
プログラム＝＞窓口
UIの窓口さんにいえば｛、、、｝なかはわからなくても大体処理できる。そういう関係
なわけよ。窓口が美人でテキパキしてないとダメだろ。
時々あるんだが、大企業の開発部に電話してるのに田舎のおばちゃんみたいなのが
窓口で
「はあ、田中さんは今日はおらんよ、どっかに出張するからって鞄を下げて出て行った
よ」
みたいな感じな。
XAMLの美人の窓口さんはどこ？　ねえ

120:デフォルトの名無しさん
16/11/10 02:08:02.40 CCFq8Qep.net
>>111
批判って言うより、ほとんどいちゃもんだけどな。

121:デフォルトの名無しさん
16/11/10 02:16:50.13 lTw5QLQW.net
長文マンは無駄に下手な比喩ばっか使って文意がわかりづらいな

122:デフォルトの名無しさん
16/11/10 02:20:15.15 aHkFnxeg.net
じゃあ具体的に書いたろか
textBox1.Text = "Hello, World!"
これでいいのに
public class Data
{
public string TextHelloWorld
{
get { return "Hello, World!"; }
}
}
example.xaml
<TextBox Text="{Binding Path=TextHelloWorld}" />
これだもんな。W
XAMLがデータを取りに行ってくれる。一見便利だが、いちいち細かい指示を出して
説明してやらんと分からんやつだから、教えるほうが手間。自分でHello！！て
書いたほうがなんぼかまし。
あれだ、パラダイムシフトだなんだって言ってるが、シフトダウンだよな。

123:デフォルトの名無しさん
16/11/10 02:26:27.64 wdbpo9Rt.net
それXAML側でName="textBox1"と定義してやれば、this.textBox1.Text = "Hello, World!"で済むだろ

124:デフォルトの名無しさん
16/11/10 02:30:19.81 YdauEkQ9.net
WPFとFormを同じXAMLから生成出来ればもっと使い道もあるんだけどな

125:デフォルトの名無しさん
16/11/10 02:31:25.72 aHkFnxeg.net
比喩だとわからんか？
窓口ってのは会社の顔だよ。XAMLの顔はというとBindingだ。ここが窓ぐち。
こいつが田舎もんだから、、、、W

126:デフォルトの名無しさん
16/11/10 02:33:21.09 4pFcdHJl.net
>>122
でもそれってXAML関係ないじゃん
なんでさっきXAMLディスってたの？

127:デフォルトの名無しさん
16/11/10 02:33:22.15 wdbpo9Rt.net
わざとミスしてレスが欲しいのか自分の主張を通したいのかどっちなのよ

128:デフォルトの名無しさん
16/11/10 02:55:22.89 bu4ikKWV.net
>>119
ぇ、それだけじゃXAMLは取りに行かないよ。
Dataクラスからの通知機構は無いの？

129:デフォルトの名無しさん
16/11/10 03:08:35.71 zCCtWAZL.net
>>115,116
？例が適当すぎて言いたいことがわからん
スクロールバーと連動して値を表示するのはバインディングで済むからUIのイベントなんて使わないだろ
UIを切り離すんじゃなくて、VとVMを切り離すのが目的

130:デフォルトの名無しさん
16/11/10 03:17:22.84 zCCtWAZL.net
>>119
バインディングする意味のないソースを出されても
さっき言ったスクロールバーとその値を表示するテキストボックスの例を見ればいいんじゃない？
バインディングを使わないとイベントを利用してそれぞれの値を相互に書き換える必要があって面倒とかそういうの

131:デフォルトの名無しさん
16/11/10 06:37:59.52 B4277xpo.net
XAMLを批判したいけどちゃんと理解してないから筋の通った批判ができない悲しさ

132:デフォルトの名無しさん
16/11/10 07:36:13.26 o8sMendu.net
>>126
例えばGridSplitter付きのパネルの開閉をアニメ付きでヤるとしたら、xamlじゃとても書けないけど
VMにやらせる仕事じゃないって場合とか、BringToViewなんかもViewで完結させるべき仕事だね
ビヘイビアやトリガーアクション使ってもいいけど無理やり突っ込むこともない

133:デフォルトの名無しさん
16/11/10 07:51:19.71 aHkFnxeg.net
<TextBox Name="Text1" Height="23" Width="70" Margin="5"
HorizontalAlignment="Left" VerticalAlignment="Top"
Text="Button" />
<Button Name="btn1" Content="{Binding Text1.Text}" Height="23" Width="70"
Margin="5,35,0,0" HorizontalAlignment="Left" VerticalAlignment="Top"
Click="Button_Click"/>
ちっともBindingせんがーーー。W
エラーもでんし。

134:デフォルトの名無しさん
16/11/10 07:53:05.39 aHkFnxeg.net
＞１２８
このバインドの書き方のどこが筋が通ってないんや？

135:デフォルトの名無しさん
16/11/10 08:11:55.57 aHkFnxeg.net
this.DataContext =this;
　そうだこれがぬけてると検索場所が特定できんのだ。
私は私ですから私を検索してくだされ。
えっ、これでもやっぱりだめ。

136:デフォルトの名無しさん
16/11/10 08:24:57.67 o8sMendu.net
彼の言うXamlの欠点とやらは、マークアップ言語ならどれでも持っているもので
xamlはｈｔｍｌと比べたら格段に進歩した代物だ
まあこんなケチを付けているんだから
ｈｔｍｌなんて触ったことない化石プログラマーなんだろうね

137:デフォルトの名無しさん
16/11/10 08:57:47.72 aHkFnxeg.net
マークアップの欠点とBindingの欠点と、、、と幾つかの欠点を併せ持っているという
ところが味噌。

138:デフォルトの名無しさん
16/11/10 09:16:40.69 o8sMendu.net
可読性を問題にしていたはずが、ロジックとマークアップが混在するhtmlを批判せずに
それを解決する方法のBindingにケチをつける
化石の末期だなｗ

139:デフォルトの名無しさん
16/11/10 09:43:37.91 aHkFnxeg.net
<Window.Resources>
<SolidColorBrush x:Key="MyBrush" Color="Blue"/>
</Window.Resources>
ボタンのインスタンスIDはNameでリソースの場合ｈｘ：Keyかよ。笑かすな。W

140:デフォルトの名無しさん
16/11/10 10:15:41.71 aHkFnxeg.net
物事を識別するには名前が肝心である。名前は適切で少ない方がいい。
大本の識別機構の混乱
XAMLコード中でIDictionaryインターフェイスを実装する要素に子要素を追加する際には
x:Key 属性の指定が必須
　ただし、Styleクラス（System.Windows名前空間）のように、クラスにDictionaryKeyPropertyAttributeを付与して、（x:Key 属性の）代替となるプロパティ（Styleクラスの場合はTargetTypeプロパティ）を設定しているクラスの場合には、x:Key属性を省略可能。
Styleクラスでは、x:Key 属性の代替としてTargetTypeプロパティを利用している。
高々リソースに名前振るだけで、、、ぷっ。

141:デフォルトの名無しさん
16/11/10 10:16:51.48 aHkFnxeg.net
>135
無批判に受け入れるのはよくない。「飼いならされて、食用にされる家畜」だよ。
In the world's broad field of battle,
In the bivouac of Life,
Be not like dumb, driven cattle !
Be a hero in the strife !

142:デフォルトの名無しさん
16/11/10 10:29:24.03 aHkFnxeg.net
＠ITデータバインディングを理解する。
URLﾘﾝｸ(www.atmarkit.co.jp)
１ページ何を言ってるのか全然わからん。突っ込みどころが多すぎて、突っ込む気にもならん。
それとも誤字脱字が多いのかな？なんか説明が間違ってるだろ。論理がつながっていない。
うちのばあちゃんにでもわかるように説明してみろや。
{Binding X}　という書き方は

143:、{Binding Path=X}　と同じ意味である。藁、「同じ意味である」って、そんなら最初から一つに絞っておけよ。 {Binding Path=X}　いらんだろ。 BindingにPath以外のプロパティはないんだろ！！　最初からBindingでいいだろパスもプロパティもいらんわ。

144:デフォルトの名無しさん
16/11/10 10:43:36.65 aHkFnxeg.net
　外部リソースを取り込むには、<ResourceDictionary>要素にSource属性を付ける
<Window.Resources>
<ResourceDictionary Source="Styles.xaml"/>
</Window.Resources>
includeにしろよな。常識だろ。

145:デフォルトの名無しさん
16/11/10 11:38:19.49 ElAt+S/3.net
質問です
フォームにプロパティグリッドがあります
プロパティグリッドの中でCtrl+Zを押したときに
普通はプロパティグリッドが持っているアンドゥが呼ばれますが
これをフォームの独自のアンドゥ・メソッドを呼び出すようにしたいのですが、
どうすればいいですか？

146:デフォルトの名無しさん
16/11/10 12:03:59.07 dRW/oH8h.net
>>141
思いつくのは、IMessageFilterを使ってWM_KEYDOWNでCtrl+Z拾ってやることかな
入力中のコントロールをControl.FromHandleで取れたら幸い

147:デフォルトの名無しさん
16/11/10 12:19:50.11 CCFq8Qep.net
>>139
Pathは省略可能ってだけで、他にもプロパティあるし。
自分で張ったリンク先の2ページ目にも書いてあるだろ。

148:デフォルトの名無しさん
16/11/10 12:41:10.63 lWSBQV9X.net
>>116
理解できない自分の頭を呪いな

149:デフォルトの名無しさん
16/11/10 12:59:35.96 otGHoxmh.net
>>142
.NET1.1の頃からそんなのあったのか
まったく知らなかったw
しかし、IMessageFilterっていうかApplication.AddMessageFilterって結構恐ろしい仕組みだなw
NativeWindowの方が安全な気がするんだけど

150:デフォルトの名無しさん
16/11/10 13:07:51.76 ElAt+S/3.net
>>142
IMessageFilterでCtrl+Z拾ってできました
ありがとうございます

151:デフォルトの名無しさん
16/11/10 14:50:01.95 zCCtWAZL.net
>>139
結局、言われた指摘には何も返せず自分が理解できないのに適当に騒いでるだけじゃん
C言語とかやったら配列があればポインタいらないじゃん！とか騒いでそう
省略可能な記述についても、html5とかの仕様を見たらhtmlとかbodyとかのタグいらないじゃん！とか叫びそう
URLﾘﾝｸ(qiita.com)

152:デフォルトの名無しさん
16/11/10 15:34:39.47 aHkFnxeg.net
グダグダ言わずに、本質はどういうことかを捉えてどう説明できるかが問題やな。
Bindingの本質はというと要するにXamlのText="{Binding pName}"　が意味するのは
var bind = new Binding("pName") { Source = per };
　 text1.SetBinding(TextBox.TextProperty, bind);
この二つの処理やないか。こいつを省略形で書いてるだけのことやろ。
チュートリアルでちゃんとこう言うように書けよな。そしたら3秒でわかるのに。
原辰。

153:デフォルトの名無しさん
16/11/10 15:45:02.09 aHkFnxeg.net
>143
１ｐが意味不明なので２ｐは見てなかった。
しかもインテリセンスが糞やからPath以外のプロパティがあるのかないのかわからん。
あくまでも
「BindingのプロパティはPath以外に無い」という前提、仮説の下でケチつけてる
わけであって、それはチャンと明記している。W
一遍にりかいするんは難しい。
OneWay ソースからターゲットへの一方通行の同期になります。
TwoWay ソースとターゲットの双方向の同期になります。
OneWayToSource ターゲットからソースへの一方通行の同期になります。
OneTime ソースからターゲットへ初回の一度だけ同期されます。
モードがあるじゃないか。ならインテリセンス効かせろや。

154:デフォルトの名無しさん
16/11/10 15:59:51.17 aHkFnxeg.net
しかしBinding部分は顔だし肝なのにここを
　正確に説明できん
　プロパティのインテリセンスも出せん
とか、要するに自分の頭で考えたものじゃなくて、アッチコッチから借りてきた借り物をくっつけ
て作り上げてるからだろ。ほんとうのところが正確に把握できてないんだよな。

155:デフォルトの名無しさん
16/11/10 16:05:52.04 aHkFnxeg.net
内容が変更したときにはどうすんの？
　INotifyPropertyChangedインターフェースを実装
　DependencyPropertyにしてしまう　（インスタンスを生成したスレッドのみに限定される）
二つの方法がある。
PropertyChanged(this, new PropertyChangedEventArgs("pName”));
プロパティの変更でこれをやってやればいい。
なんやねん。結局イベント処理は書かなだめやないか？　どんだけのメリットがあるか。W

156:デフォルトの名無しさん
16/11/10 16:10:01.34 ApowNrKS.net
ラムダ君
LINQ君
XAML君←new

157:デフォルトの名無しさん
16/11/10 16:33:44.59 aHkFnxeg.net
結局普及しないのは、関係者がちゃんと理解できていないのではないかな。
WEBを見たら、いろいろと説明が書いてるがどれも分りにくい。
C#でもVBでも1日も触っていたら、そこそこ使えるようになる。うろ覚えでも
プログラムはできる。
　WPFは説明が中途半端なので肝の部分がはっきりしない。
バインディングするんならイベントもちゃんとバインディングしないとだめだわ。
バインディングを間違っていても反応なしだしな。W　エラーすらチェックできてない。
中途半端。

158:デフォルトの名無しさん
16/11/10 17:47:19.45 riiUw9jl.net
>>152 命名のXAML君は、staticおじさんと同じ加齢臭がする

159:デフォルトの名無しさん
16/11/10 17:49:55.89 ApowNrKS.net
ラムダとLINQも新しいことを拒絶するstaticおじさんだろうな

160:デフォルトの名無しさん
16/11/10 19:15:21.25 pqjjw4yY.net
ラムダとLINQの時は使うなとか言っているやつがいたからな
拒絶するのは勝手だがいちいち布教しようとするのはウザイ

161:デフォルトの名無しさん
16/11/10 19:22:39.57 CGPJd07S.net
IEでニコ生みたいなストリーミング動画を見る際に、動画データがメモリーに展開する前にデータをリアルタイムでキャプチャするにはどうしたらいいでしょうか？

162:デフォルトの名無しさん
16/11/10 19:23:04.26 ApowNrKS.net
C#のLINQは名前が他の言語と違うから一瞬迷う

163:157
16/11/10 19:31:03.19 CGPJd07S.net
すみません分かりづらかったです。
IEで動画見ながら、IEがダウンロードしてるデータがストリーミング動画かどうかを判断して、動画ならIEの画面に表示される前に手を加えたいんです。

164:デフォルトの名無しさん
16/11/10 19:36:34.41 hirKpSKv.net
ストリーミング中の動画に手を加えられるだけの技能があるのがすごい

165:デフォルトの名無しさん
16/11/10 20:17:59.57 13nZCkn2.net
使う価値があると思えば使えばいい
自分が使うのは無理だ参りましたと思ったら使わなければいい
ただどちらを選択したかは別に他人に伝えなくていい

166:デフォルトの名無しさん
16/11/10 22:17:57.52 c1KzPo7d.net
>>159
現実的な内容じゃない
基本的に無理
プロキシ―作っても動画をいじれる技量が君にあるとは思えない

167:デフォルトの名無しさん
16/11/10 23:07:13.32 pEVMYV3p.net
IEに、そういうプラグインがあるのか、探してみれば？
IEは、オープンソース(OSS)じゃないから、改造するのは難しい。
OSSは、Firefox, Chromium, Safari
Atom, Visual Studio Code, Electron は、Chromiumを使っている

168:デフォルトの名無しさん
16/11/11 03:04:38.37 +gNs9Nbk.net
>>153
君はWPFどころかC#もよく理解できてないみたいだから、C#入門書からスタートするのがおすすめ

169:デフォルトの名無しさん
16/11/11 04:07:56.66 KgVthd+h.net
>157
ストリーミングをやるコンポーネントはあるだろ。そのデータ取り込み部分を
バッファリングして中を加工すればいいだけだろ。W
画像認識をするのかな？

170:デフォルトの名無しさん
16/11/11 07:05:40.26 KgVthd+h.net
MVVMのICommandの使い方
ICommandを実装する理由はなんだ？
　URLﾘﾝｸ(www.atmarkit.co.jp)
これは読んでいくとよくまとまっているが、これだけでは難しすぎて
何を言ってるんかわからん。まるでMS。
そもそもICommandってなーに？
1. 処理の実行可否を状態として持つ、また状態の変更を通知
2. XAMLからメソッドの呼び出しはコードビハインドしか利用できないが、ICommandはバインドが利用でき別クラス（ViewModel）の処理を呼び出すことができる
中身は
public interface ICommand
{
void Execute(object parameter);
bool CanExecute(object parameter);
event EventHandler CanExecuteChanged;
}

171:デフォルトの名無しさん
16/11/11 07:07:03.74 zUQAdwQM.net
イベントを再定義したかった人生だった(Command辞世の句)

172:デフォルトの名無しさん
16/11/11 07:08:21.41 KgVthd+h.net
いい例がある。これならわかる。これを逃してしてしまうと永久にわからないというほどの
優れた例を提示しておく。
優れた例
XAML
<TextBox Text="{Binding Name}"/>
<Button Content="実行" Command="{Binding ExecuteCommand}"/>
<Label Content="{Binding Result}"/>
ViewModel
　　public DelegateCommand ExecuteCommand { get; }
public MainWindowViewModel(){
ExecuteCommand = new DelegateCommand(() =>　Result = "登録OK",　CanExecute);
}
private bool CanExecute(){
return !string.IsNullOrWhiteSpace(Name);
}
private string _name;
public string Name{
get { return _name; }
set { if (OnPropertyChanged(ref _name, value)) ExecuteCommand.RaiseCanExecuteChanged();}
}

173:デフォルトの名無しさん
16/11/11 07:09:49.57 KgVthd+h.net
肝：DelegateCommandをプロパティとして公開
　　コンストラクタの中でインスタンス化
() =>　Result = "登録OK"
これはなんやねん？　このアクションの書き方がわからんなーという人。
ラムダ式、、、初めて聞いた？

174:デフォルトの名無しさん
16/11/11 07:13:06.18 KgVthd+h.net
＞君はWPFどころかC#もよく理解できてないみたいだから、C#入門書からスタートするのがおすすめ
C#の方が難しいわ。まあでも何とか動かせる。WPFもBindingだけわかったので何とか
使えるレベルにはなったな。
問題はMVVMパターンだな。
MVVMじゃなくてM-VM-VかV-VM-Mでないとだめだよな。VVMMの方がいいと思う。

175:デフォルトの名無しさん
16/11/11 07:23:51.87 KgVthd+h.net
WPF攻略方法
１．Bindingの理解
２．「優れた例」でVVMM（またはMVVM）を理解する　こっちはまあボチボチでもOK
MSの文書は酷いがIT－PROの文書は体裁としてはよくまとまってはいるが説明が難しい。
　第一に例が悪い。
　第二に例にセンスがない。
　第三に例の説明が下手。
単純化したシンプルな例で示さないと「俺はこんなにすごいんだぞ」みたいな
複雑な例では分からん。

176:デフォルトの名無しさん
16/11/11 08:31:34.35 KgVthd+h.net
MVVMのVMってわざわざ苦労してクラスをつくる必要あるんか？
コードビハインドをVMにしたらいいんではないか？　VとのIFはここで全部やった
らいいと思うがな。
なんか必要性がいまいちわからんなー。

177:デフォルトの名無しさん
16/11/11 08:51:31.09 qDFZLZyC.net
>>172
必要性が何なのかちゃんと調べたのかい？

178:デフォルトの名無しさん
16/11/11 09:40:30.93 yIFyhkZ0.net
DIコンテナを導入すると、VMとMの２層構造のありがたみが実感できるんだけどな

179:デフォルトの名無しさん
16/11/11 09:43:11.94 M2uBl8fv.net
>>169
ラムダ式は、Java, JS, Rubyなど、たいていの言語にある
例えば、独自の方法で、ソートしたい場合、先に比較関数を定義してから、
その関数を引数として、sort()に渡す
比較関数{ ここで定義する };
sort(比較関数);
ところが、先に定義するのは面倒だから、sort()の引数の所で、
匿名(無名)関数として定義して、そのまま引数として渡せれば、簡単。
それの糖衣構文で、関数宣言も無くしたのが、ラムダ式
JSで書くと、
var a = ["Hydrogen", "Helium", "Lithium", "Beryl-lium"];
匿名関数・ラムダ式
var a2 = a.map(function(s){ return s.length });
var a3 = a.map( s => s.length );

180:デフォルトの名無しさん
16/11/11 13:38:45.67 KgVthd+h.net
ラムダ式なんて高級なもが巷にあふれているとは初めてしった。めったに
使わないかな。
　右も左もわからないのにアンドロイドアプリ（簡単なんだが、、）を作る
羽目になってしまった。しかしXamalinダウンロードしてみたらXamlに似ていて
驚いたわ。W
　WPFを勉強したかいがあった。これからバリバリつくってみる。

181:デフォルトの名無しさん
16/11/11 18:30:50.13 ciOc6C5W.net
リスト操作系関数を一度使ってしまうともう戻れなくなる
例えば、List<string>をList<object>に変換したい時、
var hoge=list.map(x=>(object)x);
だけで良い。foreachとかで書くより楽で読みやすい

182:デフォルトの名無しさん
16/11/11 18:55:28.67 +ZeaIXfw.net
名前を付けるのも馬鹿らしい単純な操作を表現するには
やっぱりラムダ式が便利だと感じる

183:デフォルトの名無しさん
16/11/11 18:56:03.62 qDFZLZyC.net
>>176
Xamlに似てる？勘違いしてんぞお前

184:デフォルトの名無しさん
16/11/11 18:57:11.76 0OJ17qIg.net
>>177
List<T>.ComvertAll<TOutput>(Converter<T,TOutput>)ではダメなんか？

185:デフォルトの名無しさん
16/11/11 19:20:11.62 KgVthd+h.net
>179
Xamlそのものだわ。C++もC#のFormもXmalinUIもあって、3種類の開発環境がある。
まともに動けば凄いよ。W
でもサンプルを動かしたまではすんなりいったんだが署名ができないとか、文字ばけ
するとかどうも先が思いやられるのでxamalin
やめてAndroid　Studioにしようかと迷ってる。こっちはJavaだけど、、

186:デフォルトの名無しさん
16/11/11 19:58:04.56 JZCe9Y2P.net
ラムダ厨うぜー

187:デフォルトの名無しさん
16/11/11 20:14:46.10 tUVkv4AT.net
おはようラムダ君

188:デフォルトの名無しさん
16/11/11 20:20:02.48 TqB+9XQ4.net
ランバダなら知ってる

189:デフォルトの名無しさん
16/11/11 20:27:50.64 nfVHRfzR.net
>>181
c#初心者スレがあるからそっちにいった方がいい
いい加減うっとおしい

190:デフォルトの名無しさん
16/11/11 20:46:50.11 KgVthd+h.net
アッ、もうC#は卒業したんでこないよ。次はJAVAだ

191:デフォルトの名無しさん
16/11/11 20:49:06.76 nfVHRfzR.net
それは良かった

192:デフォルトの名無しさん
16/11/11 21:09:36.24 TOO7Y3Ld.net
ε-(´∀｀*)ﾎｯ

193:デフォルトの名無しさん
16/11/11 22:25:05.87 +gNs9Nbk.net
>>181
XamarinはC#に相当慣れ親しんでるか、androidもiOSもそこそこやってる人がまとめて開発したいって場面以外ではまだおすすめできる状態じゃないかな
まだ情報も少ないし、ラムダ式とかイベントとかの基本を自力で調べられない人には特に厳しいと思う

194:デフォルトの名無しさん
16/11/12 20:58:13.68 RWma0It4.net
古いWindowsマシンでAndoroid開発しようとすると
まずエミュレータが動かない
WindowsPhoneが頑張ってくれてたら
引き続きVisualStudioで開発できたのに
どうしてここまで差を付けられたのか
MSってエリート揃いじゃないのかな？

195:デフォルトの名無しさん
16/11/12 21:30:04.79 cIUa0gZx.net
古いマシンで開発するやつの事なんかMSが面倒見る義理ねえよ

196:デフォルトの名無しさん
16/11/12 23:10:09.55 l9OhshgV.net
Win10で露骨にレガシーおじさん切り捨てに来たし
流石の聖人マイクロソフトもお荷物を抱えきれなくなってきたんだろうね

197:デフォルトの名無しさん
16/11/13 02:11:36.78 PRCnkR8c.net
xamlが嫌いなら、全部コードで書けば良いのに。
Bindingが理解出来ないのなら、全部コードビハインドで書けば良いのに。

198:デフォルトの名無しさん
16/11/13 02:55:57.86 +xp6lf8w.net
WPFって学習コストが高い（少なくとも俺にとっては）から
苦労して覚えたものを擁護したくなる気持ちはわからんでもないけど、
10年経ってもほとんど普及してないのにはやっぱりそれなりに理由があると思う。
パフォーマンスの問題は目をつぶるとしても、個人的には可読的じゃないのが大きいと思うんだよね。
書いてるときはいいんだけど、自分が書いたものであっても後から見るとどこで何をやってるのか
ぱっと見て分からないし見当がつかない。
MVVM（正直これはあんまり理解してないんで誤解してるかもしれんが）にしてもそうだけど、
理念的に綺麗なのはわかるけど何か「これじゃない」感が強いというか、美しい理想の実現のための
コストが大きすぎるというか...

次ページ