WPF(.NET, WinUI) GUIプログラミング Part26

**デフォルトの名無しさん** · 2021/06/20(日) 17:04:18.66

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

前スレ
WPF(.NET4.x, .NET Core) GUIプログラミング Part25
https://mevius.5ch.net/test/read.cgi/tech/1612522463

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

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

◆zhzYcG17go · 2021/07/27(火) 13:29:46.95

>>607ですがC#ほとんど素人です
stack<t> にcanvasを入れてみてpushやpopしても上手く変更されず

**デフォルトの名無しさん** · 2021/07/27(火) 18:46:15.06

>>623
参照型が理解できてないっぽい。
残念だが初心者スレでは無いのでここまで。

**デフォルトの名無しさん** · 2021/07/28(水) 09:34:26.66

>>623
確かどっかにC#初心者スレがあったはずだから

◆zhzYcG17go · 2021/07/29(木) 12:37:19.54

こっちクローズして初心者スレ行きます

**デフォルトの名無しさん** · 2021/08/01(日) 18:11:43.70

c#に慣れてきてWPFに挑戦しようかなと公式チュートリアルのHello Goodbyeを試した。
1.まずはxamlの名前を変えましょうでエラー。
1時間ほどなら悩みまくってチュートリアルページ遥か下にデバッグの項目で意図的なバグだとわかった時はキレそうになった。
引き続き学習しようと思ってるんだけど、参考になるサイトある？

**デフォルトの名無しさん** · 2021/08/01(日) 18:45:22.56

かずき

**デフォルトの名無しさん** · 2021/08/01(日) 20:21:17.09

xamlはhtmlと同じようにタグをエディターで入力するしかないって気づいたところから使えるようになっていったな
Formsみたくコントロールをマウスで並べようとして挫折しかけた

**デフォルトの名無しさん** · 2021/08/01(日) 21:11:07.02

タグ書いて完璧なUIを作るのが楽しい
グラフィカルなエディターってチラ見するだけのものだな

**デフォルトの名無しさん** · 2021/08/01(日) 21:17:10.83

公式チュートリアルにHello Goodbye(world?) なんてあったっけ

**デフォルトの名無しさん** · 2021/08/01(日) 22:31:27.62

>>631
チュートリアル: C# で単純なアプリケーションを作成する 2021/02/10
ttps://docs.microsoft.com/ja-jp/visualstudio/get-started/csharp/tutorial-wpf?view=vs-2019

Hello Worldレベルでつまづいたのは初めてでショック。
wpf tutorialで検索したら良さげなサイト見つけられたからもういいんだけどね。

**デフォルトの名無しさん** · 2021/08/01(日) 22:31:58.77

ハロー！そしてグッドバイ！

**デフォルトの名無しさん** · 2021/08/02(月) 01:14:13.50

>>632
StartupUriを変更してないから実行時エラーになる件？
チュートリアルを手順通りやってれば悩むようなことなくね？

**デフォルトの名無しさん** · 2021/08/02(月) 12:27:13.51

>>629
Formsと同じような作り方してると結局Formsと同じくサイズ変更やレイアウト変更に脆い画面になっちまうんだよな。
GUIから貼り付けると余計なプロパティも追加されてごちゃつくし。
XAML用のコードスニペット用意して爆速コーディングがお勧め。

**デフォルトの名無しさん** · 2021/08/02(月) 17:35:01.31

縦にズラーと並べてご満悦ですか

**デフォルトの名無しさん** · 2021/08/03(火) 06:02:09.33

WrapPanelもあるでよ

**デフォルトの名無しさん** · 2021/08/05(木) 12:08:27.09

winui触ってるけど非同期メソッド多すぎてイライラする
慣れたら気にならなくなるのかな

**デフォルトの名無しさん** · 2021/08/05(木) 12:48:41.25

むしろ非同期メソッドが用意されていない方がイライラするだろ。

**デフォルトの名無しさん** · 2021/08/05(木) 21:46:17.56

>>638
WinUIまだ触れてなくて分からないんだが、もうDispatcher.Invokeしなくて良くなるの？

**デフォルトの名無しさん** · 2021/08/05(木) 22:11:14.99

きっちりMVVMしてりゃDispatcher.Invokeなんて出番ないんだが。

**デフォルトの名無しさん** · 2021/08/05(木) 22:41:02.46

>>640
https://docs.microsoft.com/en-us/dotnet/api/microsoft.toolkit.uwp.DispatcherQueueExtensions?view=win-comm-toolkit-dotnet-7.0

こんなクラス使ってUIスレッド呼び出すんだわ

**デフォルトの名無しさん** · 2021/08/06(金) 00:49:06.65

最近のアプリはクリックしたあとすぐに反応しないアプリ多すぎ。というかWindows10。

馬鹿に非同期の実装は無理ということ。

**デフォルトの名無しさん** · 2021/08/06(金) 18:59:51.04

OneNote UWP版、死亡。
着実に脱UWPしていってるな、よしよし。

**デフォルトの名無しさん** · 2021/08/08(日) 10:59:54.62

コード簡略のためにawait 使いまくってるサンプルが世に広まってるのが良くないのかね(´・ω・`)

**デフォルトの名無しさん** · 2021/08/10(火) 10:09:01.90

MahAppsでGUI作っていたけど今更Metro(Modern) UIというのもアレなんで
最近出たらしいWinUI 3.0で組もうとしているけど、ウィンドウサイズを変えることができない。

なんか、いい方法ない？

あと、WPFで使っているからかもしれないが、Windows.Storage.FilePickerの動作がなんか不安定だ。
PickSingleFileAsyncは動くのにPickMultipleFilesAsyncだとコケる。

**デフォルトの名無しさん** · 2021/08/10(火) 10:50:56.88

>>646
User32でハンドル拾ってメソッドを呼び出すと色々出来ます
いろいろ調べたけど、現状だとこうするしかない模様

**デフォルトの名無しさん** · 2021/08/10(火) 11:07:37.44

非同期じゃないとUIロックしちゃうじゃないですかーっ。（キャンセルボタンが押せない進捗ダイアログとかできてしまう）

>>647
ハンドルかぁ。
なんか以下の４種類ぐらい取得する方法あるっぽいけど違いがよくわからない・・・。

１：
[DllImport("user32.dll", ExactSpelling = true, CharSet = CharSet.Auto, PreserveSig = true, SetLastError = false)]
private static extern IntPtr GetActiveWindow();

IntPtr hwnd = GetActiveWindow();

２：
[ComImport, Guid("EECDBF0E-BAE9-4CB6-A68E-9598E1CB57BB"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IWindowNative
{
IntPtr WindowHandle { get; }
}

IntPtr hwnd = WindowHandle();

３：
IntPtr hwnd = new WindowInteropHelper(Application.Current.MainWindow).Handle;

４：
IntPtr hwnd = WinRT.Interop.WindowNative.GetWindowHandle(Application.Current.MainWindow);

**デフォルトの名無しさん** · 2021/08/10(火) 12:38:45.38

>>648
microsoft shell controls and automation　ってのをcom参照すればOK

それでWindowがアクティブな状態で
m_windowhandle = PInvoke.User32.GetActiveWindow();
な具合でOK

**デフォルトの名無しさん** · 2021/08/10(火) 15:18:02.31

WinAPI使うならPciker使うこと自体避けてしまえば
https://docs.microsoft.com/en-us/windows/win32/api/commdlg/ns-commdlg-openfilenamew

**デフォルトの名無しさん** · 2021/08/10(火) 16:38:59.72

WINUIってコントロールにハンドルないの？

**デフォルトの名無しさん** · 2021/08/10(火) 17:46:08.05

うーん、今更Windows7時代のAPIを叩くWindows API Code PackやOokiiDialogを使うのは微妙だなってことで。
Windows11になったときに浮いてしまうんじゃないかとというのはさておき、複数のファイルやディレクトリを選択できるのがいいかなと。
いつの時代なんだよといわんばかりのデザインのMessageBoxもまた然り。

>>651
ハンドルのとり方に違いはあるにせよ、だいたい以下のようなコードを使うみたいなことが書いてある。
これはとりあえず動いているコード。
[ComImport, Guid("3E68D4BD-7135-4D10-8018-9FB6D9F33FA1"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IInitializeWithWindow
{
void Initialize([In] IntPtr hwnd);
}

// ダイアログを定義
FileSavePicker picker = new()
{
SuggestedFileName = "text",
SuggestedStartLocation = PickerLocationId.PicturesLibrary,
FileTypeChoices = { { "Text File", new List<string>() { ".txt" } } }
};
// ウィンドウバンドルを取得
IntPtr hwnd = new WindowInteropHelper(Application.Current.MainWindow).Handle;
IInitializeWithWindow withWindow = picker.As<IInitializeWithWindow>();
withWindow.Initialize(hwnd);
// ファイルダイアログを表示
StorageFile file = await picker.PickSaveFileAsync();

まぁ、上のコードはちゃんと動くけど、
IReadOnlyList<StorageFile> files= await picker.PickMultipleFilesAsync();
のように複数選択にすると動かない不思議。
参考：https://qiita.com/okazuki/items/227f8d19e38a67099006

**デフォルトの名無しさん** · 2021/08/10(火) 18:43:48.86

>>652
帰ったら試してみます
どうもありがとう

**おじさん(*'▽')** · 2021/08/10(火) 19:13:20.91

GUIプログラムは、Electronを使うのが一番簡単だと思うね
ちなみにおじさん(*'▽')はJavascriptはあんまり得意じゃないな

**おじさん(*'▽')** · 2021/08/10(火) 19:18:23.47

C言語は、競技プログラミングでしか使ったことないな

**デフォルトの名無しさん** · 2021/08/10(火) 19:42:06.18

652の問題はWindowsAppSDK側の報告済みのバグだった模様。
https://github.com/microsoft/WindowsAppSDK/issues/467

>>654
まぁね～。VueとTypeScriptでいくつか作っているけど、ブラウザに用意されているOSの機能（ファイル添付とか）以外を叩かないのであれば楽。（むしろそっちのほうが得意である）

DiscordみたいなWebでもディスクトップでもってアプリを作る場合は便利だし、速度的な問題もWebAssemblyで遜色ない程度の速度で動くけど、OSの機能を叩く場合IPCRendererの知識がいるし、CのライブラリをWebAssemblyにしてJavaScriptから叩けるようにする場合は、Emscriptenの知識がいるよ。
npmで配布されているwasmなライブラリで、ブラウザでは動くのにElectronでは動かないってトラブルが結構あった。

かつてのJScriptみたく、直接COM基盤やDLLを叩けるとか、WPFを操作するのにC#の代わりにTypeScriptで組めるとかできればいいんだけどね～。

**デフォルトの名無しさん** · 2021/08/10(火) 19:59:56.48

そのへんはEdgeエンジンのWebViewに期待したいところだなぁ。

**デフォルトの名無しさん** · 2021/08/11(水) 12:43:37.02

Electron互換でwebview2使ったhta並のファイルサイズのexeかできれば覇権取れるよな

**デフォルトの名無しさん** · 2021/08/11(水) 13:03:17.24

WebViewってホストがC#ってだけで、内側からOSや.NETフレームワークの機能が
アクセスしやすくなっているわけじゃないよな。

**656** · 2021/08/16(月) 10:46:18.07

>>658
https://docs.microsoft.com/ja-jp/microsoft-edge/webview2/get-started/wpf#step-7---communication-between-host-and-web-content
を見る限り、postMessageで通信って書いてあるから、WebWorkerのWorker部分をC#で実装するみたいなイメージだと思う。

WebWorkerは以下のようにJavaScriptで並列処理する目的でよく使われるけど、DOMにアクセスできなかったりselfになるなど結構特殊だからねぇ。

呼び出す側：
var worker = new Worker('worker.js');
worker.addEventListener('message', (e) => {
console.log(e.data); // Workerから送られてきたデータ
}, false);
worker.postMessage('workerに送るデータ');

worker.js：
self.addEventListener('message', function(e) {
//なんかの処理

//処理結果を送信
self.postMessage(e.data);
}, false);

C#ではこのworker.jsに相当する部分を[webView].CoreWebView2.WebMessageReceivedで待ち受けるっぽい。

**デフォルトの名無しさん** · 2021/08/19(木) 08:23:07.44

期待

WPF 入門
https://zenn.dev/okazuki/books/windows-presentation-foundation

**デフォルトの名無しさん** · 2021/08/19(木) 08:50:27.44

>>661
分かりにくいなあ
初心者向けのチュートリアルなのかと思ったら突然妙に細かい概念の説明が入ったりWPF独自用語がロクな説明もなしに多用されてたり、
何がしたいのかよくわからん
MS技術は概念から入りがちでわかりにくいとよく言われるけど、社員もこんな感じならそらそうなるわな

**デフォルトの名無しさん** · 2021/08/19(木) 09:51:56.00

今から始めるもんでもないような

**デフォルトの名無しさん** · 2021/08/19(木) 10:31:22.37

そのサイトは読んでないけどkazukiのWPF連載は実際的だったけどなあ

**デフォルトの名無しさん** · 2021/08/19(木) 11:07:01.91

そりゃまだHello WorldにWPFの概要説明が載ってるだけだし
ただの難癖早漏

**デフォルトの名無しさん** · 2021/08/19(木) 11:44:55.48

WINUI入門お願いします

**デフォルトの名無しさん** · 2021/08/19(木) 11:46:09.64

>>664
リンク先はkuzuki氏のサイトなのだが

**デフォルトの名無しさん** · 2021/08/19(木) 15:01:24.51

WPFでも使えるプレイグラウンドってある？

**デフォルトの名無しさん** · 2021/08/19(木) 18:05:18.10

>>662
本書の対象者を見るに

**デフォルトの名無しさん** · 2021/08/19(木) 18:11:13.58

誤送信すみません

>>662
本書の対象者を見るに入門とは言ってもそこそこC#に触れてる人向けっぽいよ

**デフォルトの名無しさん** · 2021/08/20(金) 07:31:12.77

そりゃC#入門じゃなくてWPF入門だからね

**デフォルトの名無しさん** · 2021/08/21(土) 20:12:33.02

中身を見て見たけどあらかじめ知識のある人向けの入門書だから初心者には難しい
データバインディングとか普通に意味が分かる人じゃないと

入門と言うより再入門に近いかな

**デフォルトの名無しさん** · 2021/08/21(土) 20:13:15.10

WPF再入門でC#についていくら知っててもなんの意味もない

**デフォルトの名無しさん** · 2021/08/21(土) 20:23:29.65

WPFについて知りたいのにC#入門からやられてもウザいだけだわな

**デフォルトの名無しさん** · 2021/08/21(土) 20:36:08.76

秘伝のタレなんか知らんがWPFのMVVMパターンを使ったレシピがネットに転がってなくて困る。
プログラマーならフワッとした概念と、あの3つの四角形が矢印で繋がってるのだけ見て「なるほど、そういう事ね」と作り始められるの？

**デフォルトの名無しさん** · 2021/08/21(土) 20:36:30.51

旧版にあたるWPF4.5入門（https://www.slideshare.net/okazuki0130/wpf45-38048141）と
見比べてみれば、まだまださわりの部分だわな
つか、現状に合わない部分を削除してるだけに近いかね
まだ加筆が必要な部分じゃないからだろうけど

**デフォルトの名無しさん** · 2021/08/21(土) 21:03:06.13

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/21(土) 22:01:00.51

>>675
こういうのじゃないの？
https://zenn.dev/apterygiformes/articles/79a7c9e7e15106

**デフォルトの名無しさん** · 2021/08/21(土) 22:05:08.07

>>675
https://emu2021makuake.github.io/MVVM-Samples-Index/

**デフォルトの名無しさん** · 2021/08/21(土) 23:02:56.36

>>678
これは参考にしたけど途中でモデルがない？ってなったやつだわ。
>>679
こっちは見た事ないからちょっと勉強させてもらいます。

**デフォルトの名無しさん** · 2021/08/22(日) 04:37:08.19

こういうの見て正義に成ったと勘違いして
糞コード量産タイプになんだろな

reactとかだと1/10以下のコード量だぞおい

**デフォルトの名無しさん** · 2021/08/22(日) 08:24:41.03

>>680

>例えば計算機レベルのサンプル
>
>厳密に3つの責務(View, ViewModel, Model)に分けた所でPDSの冗長さが目立つだけです。
>計算機程度の小規模であるならば、ViewModelをModelと統合するのは大抵の場合あるべき姿です。

https://slidesplayer.net/slide/11235164/

**デフォルトの名無しさん** · 2021/08/22(日) 10:06:31.28

>>681
趣味で盆栽的にやってるもんだから特に発信する気もないし誰にも迷惑かけんから勘弁してよ。

>>682
数日前にこのスライド読んで、今はMVCやMVPから調べ直してるところだわ。

**デフォルトの名無しさん** · 2021/08/22(日) 13:08:52.90

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 20:28:25.21

>>684
隔離スレから出てこないように

**デフォルトの名無しさん** · 2021/08/23(月) 04:16:34.70

>>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった

**デフォルトの名無しさん** · 2021/08/23(月) 04:16:35.32

>>675
自分もそれは思ってたな
でも結局MVVMの基礎部分はこのインターフェースを使ってこの通りに実装するみたいな感じの決まり事だった

**デフォルトの名無しさん** · 2021/08/24(火) 15:32:26.18

秘伝のへたれ

**デフォルトの名無しさん** · 2021/08/24(火) 20:56:36.64

>>687
たった1週間程度だけど調べてサンプル写経して、WPFで用意されたデータバインドと各インターフェースを用いてオブジェクト指向で作ったのがMVVMになんのかなと、とりあえず理解した。
WPFでMVVMって秘伝のタレというより、作り手の匙加減で決まるお袋の味みたいなもんか。

**デフォルトの名無しさん** · 2021/08/24(火) 21:49:09.60

MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで
MVVMのベースとなるｐｒｉｍｓやMVVM Toolkitなどのライブラリはそっちで必要なDIやマルチキャストのイベントなどの機能も盛り込まれています
Windows template studioというMSによるVSの拡張機能でこれらを使った雛形でアプリを作れるけど、生成されたアプリを眺めていけば見えてくるんじゃないかな

**デフォルトの名無しさん** · 2021/08/24(火) 21:58:06.93

>MVVMは従来のWindowを幾つも開くタイプのアプリじゃなくて、1つのフレームにページを読み込むWebページのような動作をするアプリに最適なアーキテクチャで

逆に、MFCやFormsと比べてもその違いを意識することが少ないと思うが。
トップレベルの要素が<Window>かそうじゃないかの違いくらいしかないし。

**デフォルトの名無しさん** · 2021/08/24(火) 22:00:09.91

うん、あんまり関係ないね
むしろマルチページアプリをコードビハインドを最小にする純粋MVVMで作ろうとすると苦労する

**デフォルトの名無しさん** · 2021/08/24(火) 22:01:39.27

>>689
あなたが苦労して作ったのは大半が MVVM 部分じゃなくて
MVVM + α の α の部分

**デフォルトの名無しさん** · 2021/08/25(水) 03:57:42.90

VMのプロパティとXAMLのプロパティ(Text="Hello World"のTextがプロパティ)をバインディングして組んでいくのがWPFのMVVM
オブジェクト指向がどうとか難しいこと考えなくていい

**デフォルトの名無しさん** · 2021/08/25(水) 07:05:02.51

個人ツール作るだけだと設計が自由でDIで困るような事態にならないので
何もわからない状態のときに、よく見るPrismって何だとか必須なのかとか思って調べてた時間が無駄だった
入門者がMVVMを理解しようとする上で邪魔な情報が多い
今のところ手間削減のために使ってみたいと感じさせてくれるものはReactivePropertyだな

**デフォルトの名無しさん** · 2021/08/25(水) 07:50:46.77

とにかく楽してMVVMしたい人向けならCaliburn.Micro一択

**デフォルトの名無しさん** · 2021/08/25(水) 16:32:19.70

>>696
caliburnはもう死んだだろ

**デフォルトの名無しさん** · 2021/08/25(水) 16:40:02.69

>>694
自分それだわ
バインドバインドぉ！mvvm？こんなのでいいの？動くからおｋ

**デフォルトの名無しさん** · 2021/08/25(水) 16:54:38.02

ReactivePropertyでVM作るのパズル組んでるみたいで楽しい

**デフォルトの名無しさん** · 2021/08/25(水) 17:57:25.18

viewのイベントを全部vmで拾えれば楽なのに
コードビハインドからvmのコマンドつかったら疎結合ガーとか面倒くさい

**デフォルトの名無しさん** · 2021/08/25(水) 19:13:09.36

疎結合おじさん

笑

**デフォルトの名無しさん** · 2021/08/25(水) 19:17:59.52

bland用のframeworkを
mvvmと称して流布した？？だれ？(･･;)
の罪は重いな

**デフォルトの名無しさん** · 2021/08/25(水) 19:48:43.46

MVVMでイベントが使いたいときはMicrosoft.Xaml.Behaviorsを使おう
これ公式WPF拡張パッチみたいなもんだよね

**デフォルトの名無しさん** · 2021/08/25(水) 20:24:15.90

>>699
慣れたらReactivePropertyは手放せない罠
Prismはそれほどでもない

**デフォルトの名無しさん** · 2021/08/25(水) 20:56:38.65

ReactivePropertyはナシだな
個人作成のは業務で使えんわ
Prismもサードパーティ扱いだからギリNG

**デフォルトの名無しさん** · 2021/08/25(水) 21:21:12.91

ReactivePropertyやPrism相当のものをMicrosoftが用意しないのがダメすぎる。
ライブラリでもプラットフォームでも各自で勝手にやってくれがひどすぎる。

**デフォルトの名無しさん** · 2021/08/25(水) 21:25:29.69

っ Microsoft.Toolkit.Mvvm (MVVM Toolkit)

**デフォルトの名無しさん** · 2021/08/25(水) 21:45:37.63

これ来るの遅すぎた
名前空間にMicrosoftが付いてればどこの現場でも文句言われずに使えるのに

**デフォルトの名無しさん** · 2021/08/25(水) 21:47:59.78

>>705
多くのオープンソースライブラリが使えなくて大変な職場だねー

**デフォルトの名無しさん** · 2021/08/25(水) 22:07:43.44

まあガチガチな所はそうでしょう
遅れてるとしか思わんが

**デフォルトの名無しさん** · 2021/08/25(水) 22:12:40.48

リスクがあるのは事実だからねえ
JSON.NETの作者に悪意があれば明日にも.NETは崩壊するんだよ

**デフォルトの名無しさん** · 2021/08/25(水) 22:16:18.43

>>711
気になるならSystem.Text.Jsonに移行すればいいんじゃないの？

**デフォルトの名無しさん** · 2021/08/25(水) 22:21:02.62

Json.NETはMITライセンスでソースが公開されているからどうとでもなるような

**デフォルトの名無しさん** · 2021/08/25(水) 22:23:12.71

ReactivePropertyもMITライセンスだね

**デフォルトの名無しさん** · 2021/08/25(水) 22:43:32.24

そんなおいらはLitJSON
ただし日本語の扱いにちょいと問題あって自分で直す必要あるんよ

**デフォルトの名無しさん** · 2021/08/25(水) 23:13:06.54

ReactivePropertyってコレクションと双方向バインドできないよね？

**デフォルトの名無しさん** · 2021/08/26(木) 07:18:08.68

できますん

**デフォルトの名無しさん** · 2021/08/27(金) 11:29:58.61

MVVMスレが過疎ってるんでこちらで質問させてください。（>>8 その通りです）

Microsoft.Toolkit.Mvvmは、Prismなんかの外部のMVVMフレームワークに対抗して、Microsoft内で作ったMVVMフレームワーク、という認識で合っていますか？
Prismの使い方を知らないんですが、これからはMicrosoft.Toolkit.Mvvmを勉強すればいいですか？

**デフォルトの名無しさん** · 2021/08/27(金) 12:35:53.57

コミュニティツールキットの一部だけど、MS公式と考えていいと思う。
自分の使いたい機能だけピックアップして使えるし、将来性もあるし、軽量だからお勧め。

**デフォルトの名無しさん** · 2021/08/27(金) 12:47:47.66

wpf と同時期に Bland っていうデザイナーアプリが同時期にリリースされていて

wpf ： dotNet標準ライブラリ（プレーンな mvvm 機能のみ）
Bland(デザイナー) ： Bland SDK（mvvmを拡張してドラッグ＆ドロップでUIを設計出来る機能を追加）

ってすみ分けだったんだよ
dotNet標準ライブラリにはプレーンな mvvm 機能のみしか導入しないという意志に思えた
そもそも wpf ＝ mvvm 必須でもないし、
以前のFormsアプリのようにイベントハンドラー（コードビハインド）でも実装出来る

Bland SDK は Bland(デザイナー)を購入しなくてもダウンロード出来たし、
配布も自由だったから、
必要ならdotNet標準ライブラリと Bland SDKを組み合わせて使えって感じ

wpfの登場時からずっと追っかけてる俺からすると、
（wpf → Xamarin → Vue.js → React で Xaml系列は数年前に捨てた）

Bland SDK → Microsoft.Toolkit.Mvvm

に見える（Bland SDK は終了）
標準ライブラリに入るものではなく、
これらの機能はあくまでオプション扱いという事かな

**デフォルトの名無しさん** · 2021/08/27(金) 12:49:05.65

Prismは元々MSが作ったサンプルコード集で、MSがメンテを終了しコミュニティに移管された
まず確実にMicrosoft.Toolkit.Mvvmも同じ運命を辿る

**デフォルトの名無しさん** · 2021/08/27(金) 13:04:11.97

>>720
Blendでしょ

**デフォルトの名無しさん** · 2021/08/27(金) 13:48:17.67

>>722
(;´Д｀)