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

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

Windows Presentation Frameworkについて語るスレ。

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

関連スレ
Windows 10 UWPアプリ開発
http://echo.2ch.net/test/read.cgi/tech/1440150886/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/

**デフォルトの名無しさん** · 2017/05/21(日) 03:50:00.04

おじいちゃんほんと申し訳ないんだけど一生懸命覚えたであろうアセンブラの知識や機械語の知識
現代では君が信じてるほど出番無いんだわ

**デフォルトの名無しさん** · 2017/05/21(日) 05:46:56.15

大昔は、乗除算や分岐が重い処理だから少なくするんだっけ
ちょっと昔は、コンテキストスイッチに気を付けるくらい？
今は何に気を付ければいいん？
マネージ・アンマネージの行き来？

**デフォルトの名無しさん** · 2017/05/21(日) 07:59:15.03

キャリーフラグの値が欲しいときがある。

**デフォルトの名無しさん** · 2017/05/21(日) 08:09:37.53

まあ、頑張ってチマチマ最適化しようが、DataGridに数万行突っ込んだら全て終了です

**デフォルトの名無しさん** · 2017/05/21(日) 08:40:00.41

仮想化しても駄目なの？

**デフォルトの名無しさん** · 2017/05/21(日) 14:43:55.71

>>41
しょうがないお馬鹿さんだな
アセンブラっていうのはCで言えば「Cコンパイラ」に対応する言葉。
C言語に対応するのは「アセンブリ」。

**デフォルトの名無しさん** · 2017/05/21(日) 15:07:35.59

数万って実際どのくらいかな

**デフォルトの名無しさん** · 2017/05/21(日) 15:26:06.30

>>47
こういう奴は今でもD-RAMはおかしいD-RWMって言え
とか思ってるんだろうか w

**デフォルトの名無しさん** · 2017/05/22(月) 09:03:17.61

そもそもDataGridに何万件もデータを入れようなんて設計が間違っているんじゃない？
それにWPFなら仮想化できるし、そこまで問題にならないような・・・

**デフォルトの名無しさん** · 2017/05/22(月) 09:10:48.84

>>50
あのさぁ…話ループさせたいだけの下痢便くんはこの世に要らないわけ
分かる？
今すぐ中央線に突っ込んで死ね

**デフォルトの名無しさん** · 2017/05/22(月) 10:06:44.67

暑いけどまだ夏休みじゃないのにな

**デフォルトの名無しさん** · 2017/05/22(月) 11:41:08.65

毎日が日曜日なんだろ

**デフォルトの名無しさん** · 2017/05/22(月) 20:05:09.72

いまさらListViewがデフォ仮想化されててIsSelectedとBindしても同期されないって知ったのですが
仮想してる場合SelectionChangedから自力でやるしかないのですか？

**デフォルトの名無しさん** · 2017/05/22(月) 20:11:22.91

ItermsControlの仮想化は欠陥品もいいとこだから切ってるわ
あとはパフォーマンスに端から期待しない設計をすればいい

**デフォルトの名無しさん** · 2017/05/22(月) 20:56:51.57

http://stackoverflow.com/questions/31176949/binding-selecteditems-of-listview-to-viewmodel
こういうのはどう？

**デフォルトの名無しさん** · 2017/05/22(月) 21:24:33.03

>あとはパフォーマンスに端から期待しない設計をすればいい
パフォーマンスがWin Formsと同等、あとはコントロールなどWin Formsと同等のものが
早いタイミングで用意されてたら、WPFの現状も今とは多少違うものになっていたろうにな

**デフォルトの名無しさん** · 2017/05/22(月) 21:55:52.23

WPFも.NET Nativeにすれば良かったんだよ。
今からもすれ。

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

>>50
その程度の思考でプログラマーやってることにドン引きだわ。

Excelみたいなアプリを作っちゃいけないんだ。へー。

DataGridの仮想化が糞なのも有名な話だと思うんだが。

**デフォルトの名無しさん** · 2017/05/22(月) 22:40:32.33

50に設計を依頼したくないな

**デフォルトの名無しさん** · 2017/05/22(月) 22:43:05.83

>>59
WIｎFormsはListBoxやListViewがお粗末だから、見栄えの良い表にしようとするならDataGridViewを使わざるを得ないが
ｗｐｆなら大量データの表示はListViewやListBoxを使えばいい
DataGridは入力する場合だけに使えばいいから、言うほど大量のデータを扱う必要はない

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

Excelが何万件ものデータを扱うとき全部オンメモリで
やってるとでも？
その程度の思考でプログラマーやってることにドン引きだわ。

しっかし、相変わらず文句ばかりのスレだね。
そのエネルギーをもっと有効活用すればいいのに。
別にWPF使えとか強要してるわけでもなし、こんな
過疎スレにわざわざからみに来るなんて余程暇なんだな。

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

適材適所が理解出来ないお爺ちゃん達には困ったもんだよ、ほんとに。

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

どうでもいいけどD-RWMって何を考えてこういうことになるんだろかね。

ROMがRead Only Memoryだから
RAMはRead Writeとかトンデモ理論なの？

Aはなんだと思ってたのかね。
Random Access Memoryなのに。

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

>>64
横だが、ROMも機能的にはランダムアクセスメモリーなわけで、ROMと区別するための識別子としてRAMは意味合い的にふさわしくないが
定着しちまったから略語として正しいRWMじゃなくてRAMと言っている

この理屈はアセンブリ言語を定着しているからアセンブラと呼ぶことと同じ理屈だってことじゃないかな
「アセンブリ言語だーと喚くならRWMと呼べ」という主張には一定の正当性があります

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

なんか鳥頭なのかこの話の流れの突っ込みどころ、笑いどころが分かってないのが多いけど、
そもそもWPFのパフォーマンスの話の中で「アセンブラ」なんて頓珍漢な言葉が出てくるのはどうなのっていう
そこだからw

言葉遣いが不適切であるってのはついでの話

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

ループ以外のレスをしないでください

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

>>64
バカは書き込まなくていいぞ w

**デフォルトの名無しさん** · 2017/05/26(金) 00:09:01.46

XAMLのBindingで質問です。

とても単純なケースで説明すると、
XAML側でTextBoxを定義して、Textに
MainWindowに新設したstring testStringをBindするとします。

public partial class MainWindow : Window
{
public string testString { get; set; }

<TextBox x:Name="testTextBox" ～省略～ Text="{Binding testString}"/>

この状態において、

コンストラクタ内で
public MainWindow()
{
InitializeComponent();
this.DataContext = this;
testString = "1st set";
}

このコードを実行すると起動時にテキストボックスに"1st set"が入っており想定通りです。
さらに、新規ボタンコントロールを追加して
ボタンが押された際に新しい文字列をテキストボックスに設定するようにするとテキストボックスが更新されません。

private void testButton_Click(object sender, RoutedEventArgs e)
{
testString = "push Button";
}

**デフォルトの名無しさん** · 2017/05/26(金) 00:16:30.67

>>69
INotifyPropertyChanged

69 · 2017/05/26(金) 00:22:39.18

しかし、この状態で

private void testButton_Click(object sender, RoutedEventArgs e)
{
testString = "push Button";
// 以下を追加
Binding bind = new Binding("testString");
bind.Source = this;
this.testTextBox.SetBinding(TextBox.TextProperty, bind);
}

とするとテキストボックスは更新されました。

XAML側のBinding指定はコンストラクタなど各ウインドウ？が生成される時にしか有効ではないのでしょうか？
それ以後Bindされているオブジェクトが新しくなる場合は、再度バインドしなおさなくてはならないのでしょうか？

自分の理解では、
オブジェクトが更新された場合の内部挙動はBindingで所持しているプロパティパスを
DataContextからFindして該当プロパティの値を参照する、というようなイメージだったのですが、

どうもこの挙動をみていると、該当プロパティを見つけるところまでは同じですが、
見つけた後、プロパティの中に入っているオブジェクトそのものだけを記憶しているように感じます。
C++的な書き方をするなら
class MainWindow
{
string* testString;
}
// 想定していた挙動
string*& bind_property = MainWindow.testString;
// 実際の挙動
string* bind_property = MainWindow.testString;
みたいな感じですかね。新規オブジェクトのアドレスが代入されるけど、バインドは旧オブジェクトのアドレスをみているようなイメージ。

**デフォルトの名無しさん** · 2017/05/26(金) 00:28:48.35

>>70
> >>69
> INotifyPropertyChanged

testStringをMainWindowではなく
INotifyPropertyChangedを継承した別クラスにおいて、
そこで通知をうけれるようにする、という事でしょうか？

GUIコントロールからプロパティへのフィードバックが必要な場合はINotifyPropertyChanged
を使う必要があるのかなと思っていたのですが、
プロパティ->GUIコントロールだったとしてもINotifyPropertyChangedが必要なんでしょうか？

**デフォルトの名無しさん** · 2017/05/26(金) 02:07:15.36

>>72
> GUIコントロールからプロパティへのフィードバックが必要な場合はINotifyPropertyChanged
> を使う必要があるのかなと思っていたのですが、
> プロパティ->GUIコントロールだったとしてもINotifyPropertyChangedが必要なんでしょうか？

これは逆だね
>>69 のコードでもテキストボックスのテキストを打ち変えたら testString の値も変わる
(デフォルトではテキストボックスからフォーカスが外れたとき)
INotifyPropertyChanged を実装するのは testString の値が変更されたことをテキストボックスに通知するため。

> testStringをMainWindowではなく
> INotifyPropertyChangedを継承した別クラスにおいて

インターフェイスなので MainWindow に実装してもいい。もちろん別クラスでもいい。

69 · 2017/05/26(金) 23:30:26.04

ありがとうございました。
INotifyPropertyChangedで解決できました。
最終的にはPrismいれてBindableを使うようにしました。

ちなみに皆さんは、どこでWPFの情報を収集して学習しましたか？
MSDNだけで十分？
自分は本などは買っておらずネットだけでなんとかしようと思っていたのですが、
WPFのバックエンドの動作などが細かく解説してあるようなページはみつけられなくて・・。
そういったイメージがつかめるととっつきやすいかなーとおもうのですが。

**デフォルトの名無しさん** · 2017/05/27(土) 00:50:54.10

ReactivePropertyのほうが簡単でいいよ。
PrismとReactivePropertyの組み合わせが鉄板。

**デフォルトの名無しさん** · 2017/05/27(土) 22:37:08.09

>>74
書籍だとエッセンシャルかな

Google先生で十分じゃないかと
便利な世の中になったもんだと思う

**デフォルトの名無しさん** · 2017/05/27(土) 22:43:09.07

>>76
エッセンシャルに一票
てか、まともなのが和書じゃこれしか見当たらん。

69 · 2017/05/28(日) 20:09:32.80

みなさん、ありがとうございます。
参考にさせて頂きます。

**デフォルトの名無しさん** · 2017/05/29(月) 19:36:45.18

HogeViewModel は名前空間 "clr-namespace:ViewModels に存在しませんとかいうエラーに小一時間悩んだあげく
（実行はできるけどXAMLデザイナーがエラー出ていじれない）
結局ViewModelが参照してるDLLのインターフェースを実装したらそうなることが分かった・・・
意味分からん

**デフォルトの名無しさん** · 2017/06/01(木) 02:38:41.97

そんなクラス(ロードでき)ないぞ！
というエラーなわけだな

**デフォルトの名無しさん** · 2017/06/01(木) 08:18:09.78

デザイナーエラーで悩んだこと有ったが、俺の場合は古いBlendのｄｌｌがGACに入っていることが問題だったな

**デフォルトの名無しさん** · 2017/06/01(木) 15:41:03.41

ねーねー
WPFってメモリリークしやすいっていうけど、リークしてるってのはどういう手法で見つけてるの？

例えば、VS2017の場合とか

**デフォルトの名無しさん** · 2017/06/01(木) 16:26:06.42

>>82
CLR Profiler

**デフォルトの名無しさん** · 2017/06/01(木) 23:01:22.98

Prismのインストール方法教えてください

**デフォルトの名無しさん** · 2017/06/01(木) 23:04:53.79

Prismはソースコードを必要なとこだけコピペして切り貼りして使うもんだよ
ライブラリじゃなくてあくまでサンプル集

**デフォルトの名無しさん** · 2017/06/01(木) 23:35:05.61

>>84
NuGet

**デフォルトの名無しさん** · 2017/06/03(土) 09:08:04.39

>>85
ワラタw

**デフォルトの名無しさん** · 2017/06/03(土) 09:18:00.73

実際Prismは本来はそういうものだけどな
最近はフレームワークを自称するようになったけど、元々の位置付けはあくまでサンプルコード

**デフォルトの名無しさん** · 2017/06/03(土) 10:31:16.61

>>74
https://www.slideshare.net/mobile/okazuki0130/wpf45-38048141

**デフォルトの名無しさん** · 2017/06/05(月) 10:03:11.86

>>88
そんな昔話をして>>84の質問に対して何か意味あるの？
今は>>86が正解。prism 6で検索してターゲットに
合うものを入れればいい

**デフォルトの名無しさん** · 2017/06/05(月) 12:15:27.45

いや今も昔もPrismって出来合いのままで広汎なアプリの要求に対応できるようには作られてないだろ
基本的にはアプリに応じてカスタマイズして使うもんだし、それが負担になるような小規模のアプリはそもそも想定外
カスタマイズが必要になるまではライブラリとして使うというのはアリだと思うけどね

**デフォルトの名無しさん** · 2017/06/05(月) 12:18:28.84

今も2017に対応させたLivetを使ってたりする…

**デフォルトの名無しさん** · 2017/06/05(月) 12:46:14.15

誰一人としてPrismがフルスタックのフレームワークだ
なんて主張してないし
>>84はプロジェクトへの組み込み方聞いてるだけだし

**デフォルトの名無しさん** · 2017/06/10(土) 15:38:51.53

他のスレッドでインスタンス化したTextBlockを
UIスレッドでは見れないのはなぜでしょう？

**デフォルトの名無しさん** · 2017/06/10(土) 19:07:49.41

あなたが仰られているそれが理由ですよ
他のスレッドでインスタンスを作ったから

**デフォルトの名無しさん** · 2017/06/11(日) 20:58:15.69

差分アップデートの実装ってどうやってるの
差分ファイルを作るライブラリとかないすか

**デフォルトの名無しさん** · 2017/06/17(土) 21:58:05.63

>>96
DLLベースで作ってんの？
違うなら意味ない

**デフォルトの名無しさん** · 2017/06/30(金) 07:22:09.43

>>94
コントロールを作成したスレッドからしか操作できないんでしょう。
シングルスレッドアパートメントってやつ。
Win FormはそうだったけどWPFは知らない。

このスレって過疎ってるね。
WPFって需要ないんだな。

**デフォルトの名無しさん** · 2017/06/30(金) 07:51:42.00

なんだオマエ
喧嘩売ってるのか？

**デフォルトの名無しさん** · 2017/06/30(金) 07:58:29.61

Windows7 を切り捨てたくないからなかなか UWP はね…

**デフォルトの名無しさん** · 2017/06/30(金) 08:07:21.29

海外製の業務パッケージなんかだとWPF使ってるのもわりと見かけるけど、たいてい酷い品質なんだよね
別にWPFが悪いんじゃなくて、作る側が慣れてないのが使ってて伝わってくる
そもそもWPFって頭良くてWPFの仕組みも完全に理解してるアーキテクトがトップダウンで大枠から設計していくような開発スタイルに向いてて、
散らばった開発体制になりがちなドカタ開発には根本的に向いてないんだと思う

**デフォルトの名無しさん** · 2017/06/30(金) 12:42:48.11

ヘルプが充実しすぎてて語ることもない

**デフォルトの名無しさん** · 2017/06/30(金) 15:51:47.54

Livet更新する気ないなら、そう言ってくれないかな？
実はもうLivet2のリポジトリもあります！ｷﾘｯ（ｽｯｶﾗｶｰﾝ
とかほんと勘弁。

**デフォルトの名無しさん** · 2017/06/30(金) 16:07:36.83

んだねぇ・・・

**デフォルトの名無しさん** · 2017/06/30(金) 16:08:24.47

>>99
言い値で買ってくれるのなら売るけど

**デフォルトの名無しさん** · 2017/06/30(金) 16:09:51.42

>>101
もう、MVVMなんか完全に無視してXAMLの描画能力だけを使えば。
コードビハインドにイベント直書きで。

**デフォルトの名無しさん** · 2017/06/30(金) 16:22:28.05

ほんとそれで済むならそれが一番お気楽だと思うw

**デフォルトの名無しさん** · 2017/06/30(金) 20:59:06.88

WPF アプリケーションからショートカットキーで単語登録ツールを開くと、クリップボード上のテキストが単語登録ツールに送信される
https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2017/06/30/

**デフォルトの名無しさん** · 2017/06/30(金) 22:42:30.73

>>107
済まないのけ？

**デフォルトの名無しさん** · 2017/06/30(金) 22:45:54.31

バグか
多言語環境は後回しにされるからと言っても今更な問題だなー
枯れてもいないのにクラッシック扱いとかないよな

**デフォルトの名無しさん** · 2017/07/01(土) 00:25:59.28

ちょ○どさんと人脈築かないのが悪いんでしょ。:-p

**デフォルトの名無しさん** · 2017/07/01(土) 01:22:05.56

ちんぽ騎士団のことか？

**デフォルトの名無しさん** · 2017/07/02(日) 18:07:35.93

>>103
3～4年前に選定で状況がアレなんで落としたけど
未だに何かメンテされるとか思ってる人は何を見て
そう思ってる(期待してる)のかねぇ？

**デフォルトの名無しさん** · 2017/07/02(日) 18:14:09.94

>>103
あいつは信用できない人だから諦メロン。

**デフォルトの名無しさん** · 2017/07/03(月) 16:26:45.03

>>113
メンテされてるとは思ってもいないよ
Livet無しでは生きていけない体にされてしまったから、
今から新しいご主人様のもとにいけないだけ。

もうLivetなんてさわりませぇ～んｗｗｗとか言ってくれたらすっぱり諦められるのにな、って話

**デフォルトの名無しさん** · 2017/07/03(月) 16:46:48.25

PrismとReactivePropertyにすればいいのに。
化石か。

**デフォルトの名無しさん** · 2017/07/03(月) 20:11:02.99

>>106
そういうのやったことあるｗ
MaterialDesignThemeのボタンとかが欲しかったんで
Win32ダイアログのStaticに貼り付けて、SendMessageでメッセージ送信、
WPF側はCOMにしてって。

**デフォルトの名無しさん** · 2017/07/03(月) 22:28:09.60

livetはセットアップが使えるまでさわりそうだわ

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

>>116
そうする。
Livet滅びろ

**デフォルトの名無しさん** · 2017/07/04(火) 09:25:49.69

>>119
prismにしたら、序にprism.Unityも検討すると幸せになれます

**デフォルトの名無しさん** · 2017/07/04(火) 09:37:47.14

DIならAutofacの方が遥かに使いやすい

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

>>121
ｗｐｆ版のunityはごちゃごちゃしているけど、UWPはシンプルで使いやすいよ

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

autofac使いたいけどドキュメントが英語しかないのよ
unityもだけど
TOEIC500点にはしんどい

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

500あれば英語のドキュメントくらい十分読めるだろ

**デフォルトの名無しさん** · 2017/07/04(火) 13:55:29.13

何も考えないでならMEFが楽だったけど、色々問題もあるので
今はNinjectを試しに使ってみてる。Autofacは使ったこと
無いから次使ってみよう。
Unityはなんかこー使ってて芋くさい感じで即捨てたナァ。

Livetは会社の先輩にあいつについて行ってもろくな結果に
ならないよ言われたので何言ってるのか理解できなかったけど
検討すらしなかったな。
なんかそっちの業界では有名な人みたいね。

個人的には現段階で要求満たしてて物作りに使えるなら
文句言うような話でもないと思うけどさ。
コードもあるんでしょ？

**デフォルトの名無しさん** · 2017/07/05(水) 01:31:04.99

個人的にはDIはAutofacが一番活発っぽいので、将来性を見るならいいと思う。
後、使い勝手に癖があるけど、パフォーマンスを求めるならSimpleInjectorが今のところ一番かな。

**デフォルトの名無しさん** · 2017/07/06(木) 20:38:22.02

MicrosoftがUWPとXamarinのXAMLを標準化
https://www.infoq.com/jp/news/2017/07/xaml-uwp-xamarin

XAMLを使用する重要な技術のひとつはWPFだ。
BUILD Friday Q&Aに参加した.NET開発者のMorten Nielsen氏が、
MicrosoftのWindows Developer Platform担当VPであるKevin Gallo氏に、
WPFに関する同社の計画について質問している。
Nielsen氏によると、この質問に対してGallo氏は、
“XAML Standard機能への対応を目的としてWPFを改訂する計画はない”、と答えたという。
“この回答は“WPFは死んだ”という宣告に等しい”、とNielsen氏は言う。
同じ開発者のBastian Schmidt氏はこの話題について、
“MicrosoftがWPFを標準から除外すると決定したのならば、WPFの終了に関して公式声明を発表するべきだ”、
という意見を述べている。

考えられる対策として、Shaun Tonstad氏は、WPFアプリをUWPに変換する方法を提案している。
そうすれば標準においてWPFをサポートする必要はない。

　私たちはこれまで、WPFやSliverlightのアプリをUWPに書き換えてきました。
　WPFのサポートは有り難いが、
　UWPを通じたクロスプラットフォームXAML実現の妨げになるような取り組みは望ましいとは言えません。
　WPFをどう考えるかは別として、今後はUWPが重要である以上、
　クロスプラットフォームの相互運用における出発点にUWPがなるのは自然なことに思われます。

**デフォルトの名無しさん** · 2017/07/06(木) 20:46:11.26

XAML StandardはUWPとXamarin.Formsのためのもので、UWPがベースとなる。
WPFは当然そうなる。

**デフォルトの名無しさん** · 2017/07/06(木) 21:08:12.46

クロスプラットフォームか…
UWP はホント何とかしてWindows7以降位で動くようにしてほしいわ

**デフォルトの名無しさん** · 2017/07/06(木) 21:31:03.06

まあMSのプラットフォーム切り捨てはその時点ではショッキングで時期尚早のように感じられても
後で振り返ると何だかんだ言っても常に正しい決断をしてるからね
WPFはその歴史の中では長く延命させてもらえた方だったと思う

**デフォルトの名無しさん** · 2017/07/06(木) 21:58:42.48

いい加減需要無視の官僚主義でゴリ押ししても誰もついてこないって悟って欲しいよね。
UWPなんぞWPF以上に普及する訳がない。

**デフォルトの名無しさん** · 2017/07/06(木) 22:21:37.06

VB6とwinformsが細々と生き残ってるのにWPFは終了ですか

**デフォルトの名無しさん** · 2017/07/06(木) 22:28:40.73

VB6やWindowsFormsには触れてないけど、WPFと同じくレガシー扱いするんじゃないかな

**デフォルトの名無しさん** · 2017/07/06(木) 22:32:20.18

WPF→UWP移行なんて簡単にできるやん。
セキュリティに引っかかるくらいで。

WinForms連中に移行は無理だろうけどｗ

**デフォルトの名無しさん** · 2017/07/06(木) 22:41:00.13

UWP移行せえって言うことはこれまでみたいなツール類ソフトは作るんじゃねえってことだな
c++のDLLのラッパーも作れないしpythonにすら劣る環境になるぞ
戦わずして負け

**デフォルトの名無しさん** · 2017/07/06(木) 23:01:56.01

UWPなんていらんし

**デフォルトの名無しさん** · 2017/07/06(木) 23:08:26.44

UI だけ作らせてくれりゃいいよ
ちゃんと古いOSもサポートしてさ
ってことでもう全部 Xamarin でいいよ

**デフォルトの名無しさん** · 2017/07/06(木) 23:13:07.99

UWPやXamarinでは制約のせいでVS Codeすら作れないからな
electronに負けるってどういう環境だよ

**デフォルトの名無しさん** · 2017/07/06(木) 23:25:40.30

Xamarin なら UI (とロジック)以外はネイティヴで書いていいもんだと思ってたけど制約あるの？

**デフォルトの名無しさん** · 2017/07/06(木) 23:56:41.90

チョマドも切り捨てたら信じる

**デフォルトの名無しさん** · 2017/07/07(金) 00:10:38.25

VS2017のインストーラーがelectronで作られてて
MSなのになんでUWP使わないのみたいな記事があったけど
UWPは制約のせいで作れないからな