数年前、最初にWPFアプリの移植を開始したとき、私はあなたのフラストレーションレベルにありました。だから私は確かにあなたの感情を理解しています。それ以来、いくらかの進歩があり、あなたが言ったように、WinUIチームは本当に彼らの側に挑戦しています。

私の見解では、回避できない基本的な設計上の問題があります。WinRTは、C ++およびJavaScriptと直接相互運用する必要があるため、技術的に障害がありました（ここに例と別の例があり

WinRTは、Sinofskyの下でWindowsチームによっても実行されました。つまり、彼らは自分たちの世界に住んでいて、既存のエンドユーザー開発者エコシステムでの作業経験がなかったと思います。最終的に、ネイティブ開発者とマネージ開発者の両方が使用することを楽しんでいない「最小公分母」APIになりました。これは基本的に、WindowsPhoneが死んだ主な理由の1つです。開発者はアプリを簡単に開発/移植できませんでした。アプリがなければ、顧客は存在しませんでした。マイクロソフトはこの教訓を学びました。

そのため、長年にわたって慣れ親しんできたマネージコードの特典のいくつかを失いました。それは間違いなくWPFから一歩後退したように見えます-私はいつもバグや不完全な機能を見つけます。＃1830はWPFの時代には決して起こらないと思います。私たちはまだ何とか前進しなければなりません。

WinUI 3.0は明らかに、少なくともフロントエンドでこれを修正しようとする正しい方向への一歩です。ただし、Microsoftが新しいコントロールをリリースする前に、より堅牢な開発プロセスとより多くのテストを実装することを望んでいます...開発は現在プッシュ変更であり、後で修正することを知っています。これはアプリでは機能するかもしれませんが、一度設定すると後で変更するのが非常に難しいプラットフォームには適していません。（TreeView、NumberBoxなどは、最初のリリースで非常に多くの問題を抱えており、15年前の計画段階は言うまでもなく、決して戸外に出ることはありませんでした）。

かつて最も強力なUIプラットフォームであったWPFがこれに進化したのを見るのは悲しいことです。しかし、Microsoftは現在、ゆっくりと、しかし確実に、フィードバックに耳を傾け、問題を修正しています。やるべきことがもっとたくさんあることは理解されています。

robloo 2020年01月17日

👍7

ユーザーは上記を喜んでやってくれると思いますか？いいえ、そうはなりません-実際、79.8％はそうしません（私のAppCenterデータはこれをバックアップします）。ユーザーが私のアプリを使用していないか、または私のアプリが他のネイティブアプリよりも劣っているように見えるかのどちらかで私を残します。

おそらく、ユーザーが実際に考えるのをやめているという事実を考慮していないのではないでしょうか。「待って、このアプリにドライブ全体へのアクセスを許可したいのですか？」これは、アプリ/開発者/会社に精通していない人への警告です。

あなたは、低い保持率のためにアプリにドライブ全体へのアクセスを許可するためにユーザーが通過する必要のあるプロセスを非難しています。おそらく、そもそもbroadFileSystemAccessの「必要性」を再考する必要があります。むしろ、ユーザーが快適にアクセスできるフォルダーを手動で選択するようにする必要があります。

参考までに、アプリを試してみたくて、インストール後に「ねえ、どこからでもすべてにアクセスする許可を与えて」のようだったら、私も走りました。

BroadSystemAccessを要求すると、デフォルトでは、アプリケーションにはそのアクセス権がありません。

明らかに...あなたはリクエストをしただけです。ユーザーがそうすることに抵抗がない場合、ユーザーは実際にあなたにアクセスを許可する必要があります。

kmgallahan 2020年01月17日

👍3

また、 Microsoft Open Source Code of Conductに違反する無礼なタイトルのみ、およびWinUIに関するコンテンツではないことに基づいて、この問題を解決する必要があります。 @jevansaks @jesbis

kmgallahan 2020年01月17日

👎5 👍4

最後にもう1つ追加します。リッチランダーは、 1月15日の.NETコミュニティスタンドアップ（@ 1:12:40から）でそれを最もよく言ったと思います。

@verelpodeあなたは上記のビデオで言及されたラインに乗っていますが、ほとんどの部分で建設的でトピックにとどまっているので、WinUIレポへの貢献を大切にしています-最近のように、時々無駄だと感じてもコメント。

kmgallahan 2020年01月17日

BroadSystemAccessを要求すると、デフォルトでは、アプリケーションにはそのアクセス権がありません。
明らかに...あなたはリクエストをしただけです。ユーザーがそうすることに抵抗がない場合、ユーザーは実際にあなたにアクセスを許可する必要があります。

それは問題ではありません。少なくともAndroid / iOSでは、アプリがHDDにアクセスしようとしているときにそのようなメッセージが表示され、私たちの場合のように閉じられません。

jtorjo 2020年01月17日

ユーザーがアプリへのアクセスを許可する対象を選択できるファイルピッカーを提示した場合、アプリは閉じません。

代わりに、あなたはそれをすべて望んでおり、ユーザーが取らなければならないマイナーな1回限りの余分なステップについて不平を言っており、このステップであなたの保持率を非難しています。

kmgallahan 2020年01月17日

👎2 👍1

また、 Microsoft Open Source Code of Conductに違反する無礼なタイトルのみ、およびWinUIに関するコンテンツではないことに基づいて、この問題を解決する必要があります。 @jevansaks @jesbis

頭がおかしくなったとき、敬意を払うのは本当に難しいです。言うまでもありませんが、これは前にも言いましたがありません。 私が実際に書くことができれば、私は喜んで別のトーンを使用し、誰かが聞いているでしょう。上記のすべての叫びは単に存在するべきではありません-WinRTは十分に成熟している必要があります。まだ...いや...

コミュニティは実際にどこでWinRTチームと話すことができますか？聞いている人はいますか？

jtorjo 2020年01月17日

👍6

ユーザーがアプリへのアクセスを許可する対象を選択できるファイルピッカーを提示した場合、アプリは閉じません。
代わりに、あなたはそれをすべて望んでおり、ユーザーが取らなければならないマイナーな1回限りの余分なステップについて不平を言っており、このステップであなたの保持率を非難しています。

私のアプリでは、ユーザーが写真やビデオを編集できるようになっています。古いスタイルのファイルピッカーを使用するのではなく、ユーザーが選択したとおりに簡単にプレビューできるようにしたいと考えています。そうですね、すべてのHDDにアクセスできることが非常に重要です。いいえ、これらの「写真」および「ビデオ」仮想フォルダーは、ユーザーが写真やビデオを保持しているとMicrosoftが考えているものです。それは現実ではありません。

jtorjo 2020年01月17日

これは前にも言いましたが、WinRTについて書く場所はありません。

リンクが示すように、UWP Q＆AフォーラムでWinRTについてすでに怒鳴っています。ここで、移動するように指示されています。

したがって、ここに投稿することで、実際に何かを達成するのではなく、より多くのオーディエンスが必要になるようです（WinUIチームはWinRTに取り組んでいないため）。

kmgallahan 2020年01月17日

リンクが示すように、UWP Q＆AフォーラムでWinRTについてすでに怒鳴っています。ここで、移動するように指示されています。

それでも、私の問題のいずれにも解決策はありません。 Q＆Aでは、質問をしたり、回答を受け取ったりします。しかし、（残念ながら）変更するものを実際に提案することはできません。

jtorjo 2020年01月17日

私のアプリでは、ユーザーが写真やビデオを編集できるようになっています。古いスタイルのファイルピッカーを使用するのではなく、ユーザーが選択したとおりに簡単にプレビューできるようにしたいと考えています。そうですね、すべてのHDDにアクセスできることが非常に重要です。

いいえ、ちがいます。ユーザーはドライブ全体に写真やビデオを持っているわけではなく、特別なフォルダではない可能性のある特定の場所にいます。

ユーザーにこれらのフォルダーを1回選択してもらうと、

kmgallahan 2020年01月17日

@kmgallahan確かに、トーンは少しダイヤルバックできますが、私たちは以前にすべてイライラしていました。明らかな問題が解決されていないと考えるのはさらにいらいらします。人々がそれらを検証し、潜在的な解決策を提供できるフォーラムでそれらの欲求不満を発散させることは時々建設的だと思います。彼の技術的なポイントは有効です。これはWinRTとビットUWP専用であり、どちらもこのリポジトリが表すWinUIXAMLコントロールではありません。そのため、これはおそらくトピック外として閉じる必要があります。

この種の議論は、開発エコシステムの成功に対する欲求不満と多くの既得権益に起因することを知って、専門家として維持できると思います。

robloo 2020年01月17日

👍3

確かに、トーンは少しダイヤルバックすることができますが、私たちは以前にすべてイライラしていました。明らかな問題が解決されていないと考えるのはさらにいらいらします。

ありがとう：）

jtorjo 2020年01月17日

いいえ、ちがいます。ユーザーはドライブ全体に写真やビデオを持っているわけではなく、特別なフォルダではない可能性のある特定の場所にいます。
ユーザーにこれらのフォルダーを1回選択してもらうと、

明らかに、それらはそれらの特定の場所にありません。

もちろん、FutureAccessListを使用して、写真やビデオをどこに保存するかをユーザーにます。すべての写真/ビデオをどこに保存するかは誰もが知っているからです。

（私のアプリが行うこと）の代わりに、フォルダーをうまくプレビューし、写真/ビデオがあるフォルダーを表示します。

jtorjo 2020年01月17日

いくつかの注意：

@jtorjoに、あなたの経験やフィードバックについて書くために時間を割いてくれてありがとう。また、

@roblooと@kmgallahanが述べたように、これのほとんどは

ただし、Windows開発者プラットフォームのさまざまな領域に関しては、Q＆Aサイトとフィードバックハブでのエンゲージメントが向上する可能性があることも認識しています。私たちは本当に積極的にそれを改善しようとしていますが、フィードバックを提供し、何かが起こっているかどうかを確認するのに適した場所を見つけるのはイライラします。

たとえば、Feedback Hubを介して送信されるすべてのものは実際に表示されますが、応答したり、ディスカッションを続行したりするための適切な方法はありません。したがって、建設的であり、WindowsアプリのUX /開発に関連している限り、トピックが現在他の場所にうまく適合しない場合は、ここでいくつかの一般的なプラットフォームのフィードバックについて話し合うことができます。

その価値については、これらのトピックも内部の注目を集めています。プラットフォームとツール全体の主要な問題のいくつかをきちんと要約したので、共有できるこれらの領域に関する更新があるかどうかを確認するために、今日、いくつかのWinRTエキスパートに連絡しました。

デスクトップアプリ開発の場合：WinUI 3は、Windows開発者プラットフォームを分離して相互運用性の障壁を取り除き、WinUIとUWPの段階的な採用を容易にする取り組みの大きな部分を占めています。現在のすべての制限を必要とせずに、最新のUXでデスクトップアプリをより適切に有効化する必要があることを私たちは知っています。 WPFの主要な作成者の一部を含む多くの専門家が取り組んでいます。

特に、Xamlアイランドとデスクトップアプリ用のWinUIに多くの時間を費やしており、今年後半に試してみることができるプレビューをリリースする次のステップを楽しみにしています。私たちはよりフィードバック主導で透明性を高めようとしています。完全なXamlプラットフォーム（つまりWinUI 3）のようなものをオープンソースに移行するにつれて、それはより簡単になるはずです。

デスクトッププランの現在の状態に関心がある場合は、毎月のコミュニティコールの1つでもう少し詳しく説明することもできます。ここでトピックを提案してください。

WinUIコミュニティコール（2020年1月22日）＃1857

jesbis 2020年01月18日

👍9 🚀2

こんにちは@jesbis 、

私の問題を見てくれてありがとう！

@roblooと@kmgallahanが述べたように、これのほとんどは

ええ、それについて本当に申し訳ありません、私はちょうど私が私の心の外に出ていると感じました。私がここで言及したことは重要です-上記のすべてに遭遇したので、私はこれに本当に情熱を注いでいます。それらはすべて莫大な犠牲を払っており、多くの人々は単に試みさえあきらめています。

ただし、Windows開発者プラットフォームのさまざまな領域に関しては、Q＆Aサイトとフィードバックハブでのエンゲージメントが向上する可能性があることも認識しています。私たちは本当に積極的にそれを改善しようとしていますが、フィードバックを提供し、何かが起こっているかどうかを確認するのに適した場所を見つけるのはイライラします。

完全に同意。ちなみに、私は実際にフィードバックハブでbroadSystemAccessを報告しようとしましたが、すべての詳細を提供し、それに約15分を費やした後、おそらく「戻る」と同等のホットキーを押すことになりました。私はすべての作業を失いました（元に戻すことも、クリップボードにテキストがコピーされることも、何もありません）。明らかに、私はめちゃくちゃ欲求不満で、ただあきらめました。

その価値については、これらのトピックも内部の注目を集めています。プラットフォームとツール全体の主要な問題のいくつかをきちんと要約したので、共有できるこれらの領域に関する更新があるかどうかを確認するために、今日、いくつかのWinRTエキスパートに連絡しました。

デスクトップアプリ開発の場合：WinUI 3は、Windows開発者プラットフォームを分離して相互運用性の障壁を取り除き、WinUIとUWPの段階的な採用を容易にする取り組みの大きな部分を占めています。現在のすべての制限を必要とせずに、最新のUXでデスクトップアプリをより適切に有効化する必要があることを私たちは知っています。 WPFの主要な作成者の一部を含む多くの専門家が取り組んでいます。

すごい！私は間違いなくそれをもっと楽しみにしています。これが完了したらアプリを更新する可能性が非常に高いですが、それまでは多くの問題に悩まされています。

デスクトッププランの現在の状態に関心がある場合は、毎月のコミュニティコールの1つでもう少し詳しく説明することもできます。ここでトピックを提案してください。
WinUIコミュニティコール（2020年1月22日）＃1857

ここで言及したWinRTトピックを提案できますか？

再度、感謝します！

jtorjo 2020年01月18日

たとえば、Feedback Hubを介して送信されるすべてのものは実際に表示されますが、応答したり、ディスカッションを続行したりするための適切な方法はありません。そのため、建設的でアプリ開発に関連している限り、トピックが現在他の場所にうまく適合しない場合は、ここで一般的なプラットフォームのフィードバックを受け取ってもかまいません。

@jesbis
これは素晴らしいニュースです！ WinUIチームがこの柔軟性を示し、（認識された）WinRTフィードバックシステムの問題を軽減しようとしていることに感謝します。

Felix-Dev 2020年01月18日

🚀1

@kmgallahan

リッチランダーは、1月15日の.NETコミュニティスタンドアップ（@ 1:12:40から）でそれを最もよく言ったと思います。

そこでリッチ・ランダーは、少し攻撃的であると同時にいい人を好むと言っています。社会の最大の問題の一つは、多くの人が非常に「礼儀正しい」ので、彼らの行動が過激になり、表面的には「礼儀正しい」ように見えながら、無礼と無礼にひっくり返ることです。非常に「礼儀正しい」人々は間接的かつ漠然と話します、そしてこれは彼らのコミュニケーションを理解するのを難しくしそして誤解しやすくします。非常に「礼儀正しい」人々は、以下と同等のことを効果的に言っているため、無礼で失礼です。

「私はあなたが直接の真実を扱うことができないと信じているので、私はあなたを厚いふわふわの綿の手袋で扱い、あなたをプチプチに詰めて、あなたを非常に丁寧に、間接的に、そして漠然と話します。成熟した大人で私の正直な意見を表明すると、あなたはひっくり返って爆発し、狂ってしまいます。あなたは非常に壊れやすく、繊細な人であり、未熟です。したがって、私はあなたに非常に丁寧かつ間接的に話す必要があります。直接の真実を処理しないでください。」

このように、いわゆる「礼儀正しさ」を極端にすると（多くの人がそうするように）、それは「礼儀正しい」ように見えながら、無礼で失礼になります。言い換えれば、礼儀正しさと敬意の誤解は、社会の最大の問題の1つです。多くの人は、過度の礼儀正しさが無礼であり、プロジェクトが失敗するなどの原因となることに気づいていません。この誤った礼儀正しさの問題は、世界のどこかで毎日1時間ごとに毎秒さらに別の通信障害を引き起こします-それは絶えず起こります-そして社会そのせいで大いに苦しんでいます。

verelpode 2020年01月18日

🚀1 👍1

@jtorjo
問題の原因は次のとおりです。

ノキアの壊滅的な過ちの繰り返し

WinRT / UWPは、Nokia、BlackBerry、Apple、および他の企業と同じ過ちを誤って繰り返しました。ノキアの話：ノキアは非常に成功した巨人でしたが、後にノキアはスマートフォン技術に遅れをとっていることに気づきました。この問題を解決するために、彼らは既存のシステムの一連の改良されたバージョンを実現することを最優先にする必要がありました。それをする代わりに、彼らは新しいシステムに切り替えようとしました、そしてそれは彼らを殺しました。文字通り彼らを殺した-ノキアモバイルはマイクロソフトによる買収を受け入れることを余儀なくされた。

したがって、MicrosoftはNokiaの過ちから学び、同じ問題を繰り返さないことが期待されます。残念ながら、マイクロソフトはノキアと同じ過ちを繰り返しました。 Microsoftは、新しいバージョンのWPFと.NET Frameworkを作成する代わりに、WinRT / UWPに着手しました。何が起こったと思いますか？ノキアと同じ壊滅的な災害：それは彼らを殺しました。 Windows Mobileは廃止され、Microsoftの幹部によってキャンセルされました。したがって、残念ながら、マイクロソフトはノキアの壊滅的な過ちから学びませんでした。現在、すべてのスマートフォンはWinRT / UWPではなくAndroidまたはAppleのいずれかを実行しているため、WinRT / UWPは壊滅的な障害であり、Microsoftは数十億ドル規模のスマートフォン業界での地位を完全に失いました。 WinRT / UWPは、Microsoftに数十億ドルの損失をもたらしました。

BlackBerryはNokiaやMicrosoftと同じ過ちを犯しました。 BlackBerryは大成功を収めましたが、後にBlackBerryはスマートフォン技術に遅れをとっていることに気づきました。この問題を解決するために、彼らは既存のシステムの一連の改善されたバージョンを実現することを最優先にする必要がありました。それをする代わりに、彼らは新しいシステムに切り替えようとしました。 BlackBerryは当初BlackBerryOSを使用していましたが、2013年頃にQNXシステムに切り替えました。どうしたの？ WinRTおよびNokiaと同じです。それは彼らを殺しました。 2016年、BlackBerryは独自の電話の設計を中止すると発表しました。

これは、過去のある時点でAppleでも発生しました。 Appleは崩壊寸前で、生き残ることができてとても幸運でした。数年後、Appleは最終的にスマートフォンを介して強力な回復を遂げました。壊滅的なミスの後で生きていることは幸運です。

重大な変更

Microsoftは、WPF開発を継続できなかったと主張しています。変更が壊れたため、スマートフォン/タブレットにWPFを使用できませんでしたが、これは変更が壊れることを非常に恐れている場合です。はい、変更を壊すことに関して非常に注意することは賢明です、しかしそれが極端に取られるならば、それはプロジェクトと会社を殺します。現実には、重大な変更が実際に導入される可能性があります。マイクロソフトは、スマートフォン/タブレット/タッチスクリーンをサポートする「WPF5」をリリースできた可能性があり、重大な変更が含まれていると発表しましたが、開発者はすぐにアップグレードする必要はありません。既存のアプリは、アプリ開発者が快適でWPF 5に切り替える準備ができるまで、WPF 4で実行され続けるため、壊れることはありません。したがって、壊れた変更によって混乱や障害が発生することはありません。

これは、重大な変更を含む新しいバージョンのNuGetパッケージと同じ原則です。新しいバージョンのパッケージがリリースされても、アプリが突然壊れることはありません。ユーザーはアプリを使い続け、問題は発生しません。これは、アプリをアップグレードして最新バージョンのNuGetパッケージを使用する準備が整うまで、アプリが古いバージョンのパッケージを使い続けるためです。したがって、重大な変更を導入することができます。

マネージコードの見方の逆転

Microsoftによると、マネージコードには優れた利点があり、マネージコードとアンマネージコードの両方を使用した私の経験では、それは絶対に真実でした。私はアンマネージコードを書き始めました。その後、マイクロソフトの主張をテストし、マネージコードに切り替えたところ、生産性と信頼性が大幅に向上しました。その後、Microsoftは奇妙なことに彼らの立場を逆転させ、アンマネージコードと1993年からの古代のコンポーネントオブジェクトモデル（COM）、およびWin16（Win32としても知られる）の過度の使用に基づいてWinRTを作成しました。 WinRTの基盤は、何十年も古くなった技術です。ネイティブコード、COM、およびWin16 AKAWin32です。ほとんどのアプリ開発者がWinRT / UWPへの切り替えに消極的だったことは驚くべきことではありません。

Androidは現在マーケットリーダーです。 MicrosoftはAndroidから学ぶことができます。 Androidアプリは通常、マネージコードを使用して作成されます。私はJavaが嫌いで、C＃を使用することを好みますが、JavaはネイティブのWin16やCOMよりもはるかに優れていると言わざるを得ません。

複数のマイクロソフトスタッフが、それが良いことであるかのように「ネイティブ」と言い続けています。私は「ネイティブ」からキャリアをスタートしましたが、長年の経験から「ネイティブ」は悪いことだと知っています。 Android開発者の軍団も、ネイティブが悪いことであることを知っていますが、あまりにも多くのUWPスタッフがそれを素晴らしいと言っています。 @jtorjoの言葉を使用するために、WinRTチームは「現実とは接触していません」でした。 WinRTチームは、WinRTが壊滅的に失敗し、Windows MobileがMicrosoftの幹部によってすでにキャンセルされているにもかかわらず、WinRTが成功したかのように動作し続けます。

私はそれらの言葉を何度も繰り返し続けなければなりません：WinRT / UWPは壊滅的な失敗でした。 WinRTチームはWinRT / UWPが壊滅的な失敗であり、Microsoftが同じ過ちを繰り返し続けるべきではないことを認めることを拒否するという意味で、WinRTチームは「現実と接触していない」ため、私はこれらの言葉を繰り返し続けることを余儀なくされました。何も起こらなかったかのようにWinRT。

たとえば、現在DataGridは最新のマネージコードで記述されていますが、WinUIチームは、「ネイティブ」コードを使用するようにDataGridを書き直したいと考えており、実際にはダウングレードとプラクティスへの回帰であるにもかかわらず、これは「アップグレード」であると考えています。それは何十年も古くなっています。一般に、WinRT / UWPは、最新のソフトウェアエンジニアリング手法と廃止されたソフトウェアエンジニアリング手法の取り違えに悩まされています。したがって、 @ jtorjoによる「現実との接触がない」という言葉の使用は失礼と解釈される可能性がありますが、それが最良の言葉の選択でなかったとしても、それは正確な説明であると私は信じています。

_「現実との接触がない」_の別の例として、 WebView2のデザインを見てください。これは、時代遅れの概念を使用していた数十年前の私のキャリアの始まりにタイムトラベルするようなものです。最新の例外処理の代わりにHRESULTなど。 WebView2が2020年に新しいプロジェクトとしてリリースされ、それでもHRESULTやLPCWSTRなどの古い手法を使用しているのを見るのは驚くべきことです。 WebView2の設計は、最新のソフトウェアエンジニアリング手法とは無関係です。

verelpode 2020年01月18日

🚀1

したがって、Rich Landerが言ったことに沿って、私の前のメッセージはWinUIチームに対する私の礼儀正しくなるか、まったく何も言わないからです。チームを軽視した場合、私はWinUIを書き留めて無視します。メッセージを書くことはまったくありません。つまり、WinUIを「絶望的」で「失われた原因」と見なし、フィードバックを提供しません。全て。私が詳細なフィードバックを提供しているという事実は、私がチームを尊重していることを示しています。多くの人はフィードバックをしません-それはチームに無礼です。チームを絶望的であると見なすのは失礼であり、フィードバックを書く価値はありません。

もしあなたが法廷にいたら、たとえあなたが彼の内臓を嫌っていたとしても、あなたは裁判官に「あなたの名誉」を非常に丁寧に言うでしょう。極端な礼儀正しさは無礼です。裁判官は「あなたの名誉」を敬意として解釈しますが、実際には無礼です。

verelpode 2020年01月18日

Microsoftは、新しいバージョンのWPFと.NET Frameworkを作成する代わりに、WinRT / UWPに着手しました。 ..。

同意しました。私はかなりの数か月間UWPを開発してきました...かなりの数の制限がありますが、私はそれについて「禅」になるように最善を尽くし、多かれ少なかれ先に進みます。しかし、仕事をすればするほど、制限が実際にはUWPではなくWinRTであることに気づきました。

問題は、これが私たちが持っているものであり、明らかに、私たちはそれを前進させる必要があるということです。私の考えでは、これは次のようになります。

UWPは、WinRTを使用しているという事実を可能な限り隠す必要があります。
WinRTは、できるだけ多くの（不要な）制限を取り除くように努める必要があります
主な焦点はデスクトップであり、次に他のプラットフォーム（Hololens、xboxなど）です。

（psファイルの場合、そのプロパティを取得するには、非同期関数を呼び出す必要があるという事実は、それでも私をけいれんさせます）

マネージコードの見方の逆転

WinRTでCOMを処理する必要がある理由は、確かに私の理解を超えています。古いDCOMコードなどをラップしたようですが、WinRTのユーザーからは100％隠されているはずです。
COMを意識する必要があるという事実は本当に悪いです。繰り返しになりますが、ライブラリのユーザーである私からはできるだけ隠しておく必要があります。

[後で編集]考えてみると、DirectXを処理するには少なくともCOMが必要です。それでも、それは図書館のユーザーから可能な限り隠されるべきです。

複数のマイクロソフトスタッフが、それが良いことであるかのように「ネイティブ」と言い続けています。

ネイティブ、「。netネイティブにコンパイル」のコンテキストでは、良いことだと思いますが、その制限は好きではありません。私のプロジェクトは、UWPに移植した別のlibを使用し、強力なストアの人が「受け入れられない」と信じているいくつかのAPIを使用しているため、.netネイティブにコンパイルできません。問題のライブラリはhttps://github.com/naudio/NAudioです-非常に強力なライブラリです。この理由だけで、私は単に言いました-私は自分のアプリをMSストアに公開しません。

_「現実との接触がない」_の別の例については、 WebView2のデザインを見てください。これは、私のキャリアの最初にタイムトラベルするようなものです。

100％確信はありませんが、おそらくあなたは正しいでしょう。 WebViewがWin32コントロールのラッパーであると言われていることは知っています。また、WebViewが別のコントロールの上にあると、WebViewリンクが機能しないという奇妙なバグを知っています。

jtorjo 2020年01月18日

👍1

こんにちは@robloo 、

返事が遅れて申し訳ありません

数年前、最初にWPFアプリの移植を開始したとき、私はあなたのフラストレーションレベルにありました。だから私は確かにあなたの感情を理解しています。それ以来、いくらかの進歩があり、あなたが言ったように、WinUIチームは本当に彼らの側に挑戦しています。

はい、完全に同意します。 2016年から2017年にかけて、私はUWPにさえ触れませんでした。

私の見解では、回避できない基本的な設計上の問題があります。WinRTは、C ++およびJavaScriptと直接相互運用する必要があるため、技術的に障害がありました（ここでは

控えめに言っても、それは悲しいことではありません...なぜJSの相互運用性が必要なのですか？

...は例であり、別の）です。ジェネリックなどの高レベルの概念の多くでは、実際にはうまく機能しません。もちろん、このアーキテクチャにも大きな利点が1つあります。それは、すべてのWindowsが同じWinRTAPIを共有できるようになったことです。

WinRTについて私が嫌うものはたくさんあります-リストにもう1つありますか？

私もこれについて知る必要があるという事実は悪いです。実際、私はそのような2つの小さなプロジェクトを作成する必要がありましたが、実際に何を使用できるかを理解するには、すべて試行錯誤でした。

そのため、長年にわたって慣れ親しんできたマネージコードの特典のいくつかを失いました。それは間違いなくWPFから一歩後退したように見えます-私はいつもバグや不完全な機能を見つけます。＃1830はWPFの時代には決して起こらないと思います。私たちはまだ何とか前進しなければなりません。

ええ、私たちは...

WinUI 3.0は明らかに、少なくともフロントエンドでこれを修正しようとする正しい方向への一歩です。ただし、新しいコントロールをリリースする前に、Microsoftがより堅牢な開発プロセスとより多くのテストを実装することを望んでいます... [...]

100％同意しました。

かつて最も強力なUIプラットフォームであったWPFがこれに進化したのを見るのは悲しいことです。しかし、Microsoftは現在、ゆっくりと、しかし確実に、フィードバックに耳を傾け、問題を修正しています。やるべきことがもっとたくさんあることは理解されています。

はい、MSには明らかに素晴らしい人々が耳を傾けています。これを好転させることができることを願っています...

jtorjo 2020年01月18日

ファイルAPIのクエリが遅い

どうやら、誰かがこれに対する回避策を見つけました。明らかに、これに時間がかかったのは本当に悲しいことです。これは、ファイルの検索を処理するための好ましい方法ではありませんが、少なくとも実際には機能します。
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

だから、 @ duke7553に感謝し

jtorjo 2020年01月19日

@jtorjo喜んでお手伝いします！

duke7553 2020年01月19日

👍1

この議論は非常に興味深く、実際にはWindowsUIの将来に非常に関連していると思います。これは、WinUIが孤立していないためです。このリポジトリ全体は、WinRT / UWP以外で実行されるアプリの作成に役立たない限り、ほとんど価値がありません。 WinUI3.0はすぐに来ることができませんでした。

WindowsのUIのビジョンとロードマップがありますが、それはスタックの最上部にあり、その表面層の下にあるもののビジョンはありません。
WinUIは見栄えが良いですか？はい
今すぐWindowsでモダンで見栄えの良いアプリを作成できますか（2020年1月）。番号
UWPで優れたアプリを作成できますか？地獄！

部屋の中の象に対処せずに前進することはできません。前述のように、WinRTとUWPは、ビジネス面だけでなく技術的にも完全な失敗でした。私は個人的に体の数の中にいます。アプリがフォーカスを失ったときにサウンドを再生する方法がわからなかったため、趣味のプロジェクトの開発をやめました。些細なことです。些細なことはUWPと同じくらい難しい必要がありますか？些細なことが不可能なほど難しいときに、プラットフォームを素晴らしいと呼ぶことができますか？ WinUIはプラットフォームの一部にすぎませんね。

部屋の中の別の象。誰かが尋ねた場合：新しいWindowsプログラムを作成したいのですが、それを行うための最良の方法は何ですか？ JAN2020には正解はありません！ UWPを答えに入れようとすると、ひどい時間を過ごすことになります。（コメント、ブログ投稿、YouTubeビデオで、誰かが言ったものはありますか：UWPで素晴らしいアプリを作成し、そのプロセスが気に入りましたか？そうではないことは誰もが知っています。UWPでアプリを作成することについて書いている人は誰もいません。インターネット上には存在しません）。 WPF？現代のコントロールはありません-死んだ技術、良い考えではありません（ただし、UWPよりも優れています）。正直な答えは、電子を試してみてください。 VSCodeはそれで作られているので、あなたはそれで良いアプリを作ることができることを知っています。

そして、あなたが好きな言語でウィンドウズ用のアプリを作ることができるというこの考えは、単なる取り締まりです。私たちは、あなたが望むどんな言語でも非常に悪いUWPアプリを作ることができる状況にあります。ボットは、それを行うための少なくとも1つの優れた方法ではありません。

スレッドで前に述べた卑劣なこと？完全に同意します。 Visual Studio-Juggernaut自体（UI）は、マネージコード-WPFで作成されています。それは素晴らしい、素晴らしいです。 Microsoftでさえ、この想定されるsuperionネイティブコードでOKアプリを作成することはできません。 OneNote、Weather、さらにはスタート/検索/タスクバーで、毎日予期しない動作が見られます。不安定な感じがし、フォーカスが正常に機能しない場合があります。

これは豊かで重要なトピックです。 WinUIに非常に関連しており、悲しいことに、それについて話すのにこれ以上の場所はありません。これらのトピックは、Microsoftがオープンな方法で処理する必要があります。

AndrewPawlowski 2020年01月19日

👍6

WindowsのUIのビジョンとロードマップがありますが、それはスタックの最上部にあり、その表面層の下にあるもののビジョンはありません。
WinUIは見栄えが良いですか？はい

はい、そうです！

今すぐWindowsでモダンで見栄えの良いアプリを作成できますか（2020年1月）。番号

私はあなたができると信じています-しかしそれは本当に本当に難しいです。些細なことをするのはめちゃくちゃ難しいです（私はそれが可能であることを証明していますが、確かに鋼の神経が必要です）：

UIの面では問題が発生しますが、通常はコツをつかむでしょう
「その他」の面では、物事はかなり薄暗いです。
StorageFile / Folder APIのおかげで、UWPでのファイルの処理は完全に地獄です。これは、中途半端に言えば、心から嫌いです。

部屋の中の象に対処せずに前進することはできません。前述のように、WinRTとUWPは、ビジネス面だけでなく技術的にも完全な失敗でした。私は個人的に体の数の中にいます。アプリがフォーカスを失ったときにサウンドを再生する方法がわからなかったため、趣味のプロジェクトの開発をやめました。些細なことです。些細なことは彼らがいるのと同じくらい難しい必要がありますか

同意しました。実際、WPFではSystemSounds.Beep.Play()ようなシステムサウンドを再生しますが、UWPでは使用できません。

基本的に、「優れた」WinRT制限のため、UWPにはサウンドライブラリがありません。これは、基本的に、win32であるDLLから関数をインポートできないことを意味します。ほとんどの場合、すべての適切なライブラリをUWPに移植することはできません。ライブラリもアプリもありません。

UWPの「サウンドライブラリ」では、naudioはUWPでの作業に最善を尽くしています。明らかに、それは横ばいになりました。私はフォークを行い、多くの#ifdefを削除しましたが、今では私のニーズに合っています。アプリをMSStoreに公開することはできませんし、公開したくもありません。

私の考えでは、正しい方向への最善のステップは、MSが

最後に、WindowsデスクトップFIRSTに焦点を当てます。 HololensやXboxなどの1000のプラットフォームを追いかけるのはやめましょう。確かに、それらのプラットフォーム用に開発したい人もいるでしょうが、その割合はごくわずかです。
APIに関してすべての制限を削除します-人々が実際にライブラリをUWPにコンパイルできるようにします
BroadSystemAccessをリクエストしたら、それを与えて、過度に保護
BroadSystemAccessをリクエストしたら、すべてのHDDでSystem.IOを許可します
MSストアの外部に簡単に配布できるようにします（+「新しい証明書」の問題を修正します）

部屋の中の別の象。誰かが尋ねた場合：新しいWindowsプログラムを作成したいのですが、それを行うための最良の方法は何ですか？ JAN2020には正解はありません！ UWPを答えに入れようとすると、ひどい時間を過ごすことになります。（コメント、ブログ投稿、YouTubeビデオで、誰かが言ったものはありますか：UWPで素晴らしいアプリを作成し、そのプロセスが気に入りましたか？そうではないことは誰もが知っています。UWPでアプリを作成することについて書いている人は誰もいません。インターネット上には存在しません）。 WPF？最新のコントロールはありません-

はい、同意します。UWPで適切なリソースを見つけることはほぼゼロです。多くの問題は、自分で取り組み、修正する必要があります。

死んだ技術、良い考えではありません（ただし、UWPよりはまだ優れています）。正直な答えは、電子を試してみてください。 VSCodeはそれで作られているので、あなたはそれで良いアプリを作ることができることを知っています。

WPFについて私は賞賛の言葉しかありません。私はかなりの数年間開発してきました。学習曲線はかなり急ですが、一度コツをつかめば、それは驚くべきことです！修正されないことがわかっていたハードコアバグをいくつか見つけましたが、それだけです。

アプリを十分に高速化するためにwin2dを使用する必要があったため、UWPへの移行を余儀なくされました。 UIに関してはUWPに欠けているものがあります（たとえば、移植を開始した時点では、コントロールのCursorを定義するネイティブな方法がありません）が、全体として、常に回避策を見つけました。

スレッドで前に述べた卑劣なこと？完全に同意します。 Visual Studio-Juggernaut自体（UI）は、マネージコード-WPFで作成されています。それは素晴らしい、素晴らしいです。マイクロソフトでさえできませんが

明らかに、私はあなたが私の人生の間UWPでVisual Studioを作成することができなかったことに賭けます-そして私はUIについて話していません、あなたはVisual StudioのUIに匹敵し、それを超えることができますが、残りは。 ..。。

これは豊かで重要なトピックです。 WinUIに非常に関連しており、悲しいことに、それについて話すのにこれ以上の場所はありません。これらのトピックは、Microsoftがオープンな方法で処理する必要があります。

100％同意しました！

jtorjo 2020年01月19日

👍5

今すぐWindowsでモダンで見栄えの良いアプリを作成できますか（2020年1月）。番号
私はあなたができると信じています-しかしそれは本当に本当に難しいです。些細なことをするのはめちゃくちゃ難しいです（私はそれが可能であることを証明していますが、確かに鋼の神経が必要です）：
UIの面では問題が発生しますが、通常はコツをつかむでしょう
「その他」の面では、物事はかなり薄暗いです。
StorageFile / Folder APIのおかげで、UWPでのファイルの処理は完全に地獄です。これは、中途半端に言えば、心から嫌いです。

私たちはここで殴られた犬のようです。 Windowsデスクトップ用の新しい最新のアプリを作成するのは実際には非常に困難です。アプリを実行するための優れた方法が少なくとも1つあるべきではありませんか？ WindowsでMicrosoftStoreにアクセスしてアプリのカテゴリをスクロールしようとすると、UWPで作成された適切なアプリは見つかりません。ところで、私はそれを自分でチェックすることはできません...

うん、「モダン」、「ネイティブ」アプリの紳士淑女。 Windowsは現在実質的に無料であるため、収益化の主なソースはシステム上で最も堅実なアプリであるべきではありませんが、私は逸脱します。実際にアプリを調べて、それがどの技術で作られたのかを知る必要はありません。一見すると、UWPで構築されているかどうかがわかります。 UWPを使用して構築された本格的な商用プロジェクトはありません。UWPを使用して構築されているのは...ご存知のとおり...

そしてそれはそれがすっごく難しいからです。 Window10は、インターネットとAndroidに次ぐ最大のプラットフォームです!!! しかし、その目的のために作られたと思われるツールを使ってアプリを作っている人は誰もいません！それについて考えてみてください。 UWPを搭載したWindowsだけでなく、3つのオペレーティングシステム用のElectronアプリを作成する方が簡単です。

優れたツールを要求するためにWindowsデスクトップアプリを構築したいだけの私たち、殴られた犬にとっては大丈夫ですか？私は申し訳ありませんがそう言います！しかし、私たちが持っているのはマイクロソフトからの無線封止だけです。アプリがHoloLens、Windows Phone、Xboxで動作する可能性があるというおとぎ話を聞きたい人はいますか？誰でもない。 5年後、UWPで約束されたプラットフォームの2つで動作する商用アプリはありませんでした。（主に、これらのプラットフォームが終了しないためです）。もう一度、それを熟考してください！私たちに起こった最高のことは、WinUIが古いwin32に移植されていることです。

私はWindowsデスクトップが大好きで、WinFormsとWPFでC＃を実行するようにプログラムすることを学びました。そして、それは私がそうであったように初心者にとって簡単で優れていました。今日、私はWinUIのこれらのジューシーなコントロールを見て唾を吐きますが、誰かがプラットフォームの全体像を明確にする必要があります。一部のMS経営幹部の市場志向についてではなく、実用的なテクノロジーのリーダーシップについて明確なメッセージが必要です。

AndrewPawlowski 2020年01月19日

🚀6

やあ、
私はこの議論に少し遅れていますが、とにかく謙虚な意見を述べたいと思いました。
商用UWPアプリに関して：私の頭に浮かぶのはAdobeXDです。これはUWPであり、非常に成熟していて完全な感じがします。
13年間.Net開発者であるUWPでの私自身の経験：もちろん、それを使用して見栄えの良い、パフォーマンスの高いアプリを作成できます。しかし...それは美しい経験ではありません。私たちは医療アプリケーションを作成している最中であり、ここや他の場所ですでに言及されていることの多くは私たちにも遭遇しました：

信じられないほど遅いファイルAPI
非常に遅い「F5時間」。したがって、デバッグに入ってアプリケーションをビルド/起動して何かを試すのは、WPFよりも少なくとも10倍遅くなります。（Surface Book 2では約2分と考えてください）
一般的に、サンドボックスによって制限されています。
これらは私の頭の上からのものです。最終的に、XamlIslandsがリリースされたとき、すべての背後に高速の.netコアを備えた完全なUWPUIをWPFウィンドウでホストすることを選択しました。 XamlIslandをこの規模で使用している人はあまりいないと思います（私たちが作成したgithubの問題/ PRから結論付けています）。しかし、このテクノロジーにはいくつかの非常に深刻な制限もあります。一例として、コンパイル時間はさらに長くなります。 Xamlのライブ編集機能が失われます。本格的なWPF / XamlIsland / UWPアプリのインストーラーを作成しますか？それは痛い。 NS...
つまり、美しいUWPアプリを作成することはもちろん可能です。しかし、それはとても非生産的で遅いです。そして制限されています。
そのため、他の多くのユーザーと同様に、WinUI 3のリリースと成熟を待ち望んでいます。これにより、「UWP」フロントエンドと.netコア（または.net 5 ;-)）バックエンドをトリックなしで使用できるようになります。

jasonwurzel 2020年01月20日

@jasonwurzelこれらはいくつかの非常に良い点です
ファイルAPIは遅いですが、それまでの間、 @ duke7553は＃1465に回避策を投稿しました（コメント）
それは本当ですが、当時はそれについて知りませんでした。言うまでもなく、ファイルI / Oを高速化するためだけに、この回避策を実装するのはどういうわけかクレイジーです...
F5時間は物事を遅くします、そしてそれはいくつかの改善を使うことができると思います
xamlアイランドルートを使用するのではなく、通常のUWPアプリを開発しようとすると、どのような制限に遭遇したのでしょうか。現在、いくつかのアプリに取り組んでおり、Win32プロセスを含めることで制限を解決することができましたが、アプリを作成するための理想的な方法であるとは限らないことを理解しています。
結局、それは私たちが遭遇した障害の合計だったと思います。間違いなく、そのいくつかは外部プロセスで解決できたはずです。順不同：
挿入されたメディアのCDトレイ/ USBポートの観察
ローカルPCの任意の場所でユーザーが選択したディレクトリを監視し、更新時にアプリ/ Windowsにアクセス権を記憶させる
BroadFileSystemAccessを要求し、例外を取得し、対応するWindows設定ページを開くと、ユーザーはアプリのトグルを確認し、ブームアプリは警告なしに閉じ、介入する機会はありません。
同じドメイン：ユーザーがWindowsスタイルのFolderPickerを開かなくてもディレクトリを選択できるようにします（フルスクリーンアプリを適切かつ合理化された方法でスタイル設定したくない場合は、Windowsダイアログがユーザーの顔にジャンプします）
鶏が先か卵が先か問題：nugetパッケージの可用性/サポート（まだ多くの人がWPFを使用しているため、小さな問題の解決策を見つけるのがはるかに速くなります）
インストール場所の制御

jasonwurzel 2020年01月20日

🚀2

@AndrewPawlowski GitHubのオープンソースを含む、モダンで見栄えの良い優れたUWPアプリがたくさんあるとしたら、驚くでしょう。
何かをする方法がわからなかったためにアプリの作成をあきらめたからといって、プラットフォームが失敗したことを意味するのではなく、アプリが失敗したことを意味します。周りを見回すと、アプリがフォーカスを失っても音を鳴らし続けるアプリなど、一生懸命働いて本当に良いアプリを作成した多くの開発者を見ることができます。

それが不可能だと言っているわけではありませんが、それは非常に難しいことです。そして、私は単純な「メモ帳のような」アプリについて話しているのではなく、UI /ビデオ編集/サウンド編集/ロード/ディスクへの多くのものの保存/（試行して成功しない）を扱う非常に複雑なアプリについて話している）起動するもの（そしてfullTrust APIについて教えてはいけません）。私は50〜10万行以上のコードアプリについて話しています。

それはもっと難しいです。

そして、アプリがフォーカスを失ったときにサウンドを再生できるという事実-誰もあなたができないと言っているわけではありませんが、それは今よりも簡単なはずです。

UWPアプリの開発プロセスを楽しんでいる人がいるかどうかを尋ねると、その答えはたくさんあり、ここ数か月、他の開発者からアプリのヘルプを求めるリクエストがたくさん寄せられているため、プラットフォームは明らかに関心を集めています。

同意するので、実際にアプリをUWPに移植することに着手しました。しかし、それは非常にでこぼこの道であり、今でもそうです。

また、UWPアプリの開発について書いている人は誰もいないと主張しますが、それは誤りです。 @ rudyhuyn 、Martin ZikmundはUWPについて書いている開発者のほんの2つの例ですが、他にもたくさんあります。

私は完全に同意しますが、それをwpfについて書いている人々と比較してください。それは水滴です。

単純なgithub検索を実行するだけです-「c＃wpf」（3701件の結果）と「c＃uwp」（337件の結果）。
同じことを検索し、「コミット数> 500」（つまり、ユーザーがプロジェクトに固執していることを意味します）でフィルタリングすると、かなり暗い画像が見つかります。

これは、2020年に見栄えの良いアプリと最新のUWPアプリの両方を作成できることと、ステートメントの多くが正確でないことをほぼ示しています。

UWPの複雑なアプリを開発し、それを喜んで実行できるようにするために、私は同意しないように頼みます->私たちはそれから遠く離れています。

jtorjo 2020年01月20日

xamlアイランドルートを使用するのではなく、通常のUWPアプリを開発しようとすると、どのような制限に遭遇したのでしょうか。現在、いくつかのアプリに取り組んでおり、Win32プロセスを含めることで制限を解決することができましたが、アプリを作成するための理想的な方法であるとは限らないことを理解しています。

私の側では、9月にXamlIslandsを使用してwin2dを使用しようとしましたが、1ビットは機能しませんでした。 MSの例をいくつか試しましたが、どちらも機能しませんでした。その時点で、アプリをUWPに移植する必要があることに気付きました。そうしないと、これは機能しません。

最近のテストについては-https：//github.com/microsoft/Win2D/issues/731

jtorjo 2020年01月20日

非常に遅い「F5時間」。したがって、デバッグに入ってアプリケーションをビルド/起動して何かを試すのは、WPFよりも少なくとも10倍遅くなります。（Surface Book 2では約2分と考えてください）

そうそう！私はこれについても言及しませんでしたが、ええ、それはめちゃくちゃ遅いです。コンパイルするプロジェクトとコンパイルしないプロジェクトを微調整することでそれを回避しました-そして、私が取り組んでいるアプリのどの部分に応じて、これはまともなまたは恐ろしいです（そしてまともな、つまり、およそ10〜15ほとんどの場合秒）

一般的に、サンドボックスによって制限されています。

そうそう：）

jtorjo 2020年01月20日

ファイルAPIは遅いですが、それまでの間、 @ duke7553は＃1465に回避策を投稿しました（コメント）

同意しましたが、誰かがその回避策を見つけるのにどれくらいの時間がかかったかを考えてみてください。それは明らかに存在していましたが、ドキュメントに深く埋もれていました。そして今、おそらくごく少数の人々がそれを知っています（私を含む）。

グーグル検索を行った場合、その回避策を示す投稿は見つからないため、ほとんどの開発者が気付くまでにはおそらく数か月かかるでしょう。

jtorjo 2020年01月20日

@jasonwurzel

そのため、他の多くのユーザーと同様に、WinUI 3のリリースと成熟を待ち望んでいます。これにより、「UWP」フロントエンドと.netコア（または.net 5 ;-)）バックエンドをトリックなしで使用できるようになります。

MSが、.NET 5がリリースされると、UWPプロジェクトに問題なく使用できるようになると言ったことを指摘しておきます。「トリック」や.NETCore3.xのような状況は必要ありません。これが.NET5の発表の投稿です： https ：

Felix-Dev 2020年01月20日

ええ、それは私が言及していたものです👍

jasonwurzel 2020年01月20日

_「完全に現実と接触していない」_の「完全に」という言葉は不公平で不正確だったと思いますが、 完全に現実に触れていなかった場合、WinUIチームはWinUIをUWPから分離することに取り組んでいません。全体として、WinUIチームは、UWP / WinRTの他の部門よりも連絡が取れているようです。正確な説明は、現時点で一部のチームにある程度の非接触が存在するということだと思います。

列付きリストGUIの重要性

WinUIチームは、UWP / WinRTに関連するすべてのチームの中でおそらく最もパフォーマンスの高いチームですが、WinUIのプロジェクト管理にはまだいくつかの間違いがあったと思います。 列付きリストGUI （ DataGrid ）は、すべての顧客が日常的に使用する重要な主流機能です（WindowsエクスプローラーやSpotifyなどの他のさまざまな例など）。 WinRTの開始以来、列付きリストGUIの公式サポートがない状態で8年になります。 この状況は衝撃的だと思います。その理由やその他の理由から、UWPは今日でもアルファ版であると言います（まだ機能が完全ではないため、真のベータ版ではありません）。ほとんどのアプリ開発者がUWPを真剣に受け止めなかったのは当然のことであり、そのためWindowsMobileはキャンセルされました。

WinUIのDataGridの公式バージョンは、過去8年間延期されています。 Microsoftが新しいシステムを起動するべきではなかったため（Nokiaなどに関する以前のメッセージで説明したように）、WinRT1.0がリリースされた瞬間にDataGridが期限切れになりました。ミッシングファンダメンタルズで8年、8年遅れ、そして今WinUIチームは、ネイティブコードにダウングレードすることでさらに多くの時間を無駄にすることで、DataGridをさらに遅れさせたいと考えています。複数の理由から、UWPを真剣に受け止めることは難しく、信頼することも困難です。

C ++ / CXは最近C ++ / WinRTに置き換えられました

「現実と接触していない」という別の例を次に示します。
明らかに、ソフトウェアは正気の方法で書かれる必要があります（私は用語として「正気」を意味し、「あなたは正気ではない」などの侮辱ではありません）。用語としての「正気」とは、単純で単純なタスクを実行するために、あいまいな複雑な黒魔術を使用してはならないことを意味します。
C ++ / CXは最近、C ++ / WinRTに置き換えられました。 C ++ / WinRTは、静的ディスパッチを介した関数呼び出しに、いわゆる_「不思議なことに繰り返されるテンプレートパターン」_を使用します。それは単純で単純なタスクを達成するためにあいまいな複雑な黒魔術を使用する場合であるため、それは正気のデザインではないので、それは本当にひどいデザインです。さらに、CLR / C＃はすでに数十年前にこの問題を解決しました。それでは、なぜWinRTチームは、数十年前にすでに解決された非常に古くて原始的なトピックをいじり回して時間を無駄にしているのでしょうか。 WinRTチームが車輪の再発明を行うのはなぜですか？

C ++ / WinRTの新しいソースコードを閲覧したところ、非常に低品質のソフトウェアであるという印象がありましたが、WinRTチームはそれを非常に高度なものと見なしています。したがって、「現実との接触がない」というのは正確な説明です。

UWPファイルシステムはまだアルファ版です

@jtorjoや他の人々は、UWPのファイルシステムAPIのパフォーマンスの問題について言及しています。パフォーマンスは、フィーチャーコンプリートのベータ版として説明するのに必要なレベルを下回っています。 UWP FS APIがまだアルファ版であるもう1つの理由は、フォルダーを移動する機能がないことです。 25年前、Windows 95にはフォルダを移動する機能がありましたが、UWPにはまだこの基本的な機能がありません。ある意味で、Windows95はUWPよりも強力です。さまざまな点で、WPFと.NETFrameworkはUWPよりも強力です。 Microsoftは、アプリ開発者がUWPを真剣に受け止めることを期待していましたが、MicrosoftがUWPをアルファ段階からベータ段階に進めなかったため、これは非常に不合理でした（または「現実との接触がない」）。

verelpode 2020年01月20日

👍4

Windowsは、「App Dev」のようなモバイルが活況を呈している市場であり、セキュリティとバッテリー寿命を中心に持つという点で現代的であると想定していました。

彼らは市場の力のためにモバイル市場から追い出されました。 HololensやXboxなどのデバイスは、Win32のレガシーサポートを削除しようとしています。これにより、開発が簡単になり、よりスリムでパフォーマンスの高いOSコードベースになります。

これらの賭けは完全には報われていませんが、最新のアプリ配信とセキュリティモデルの理想は称賛に値する目標です。

そのため、いくつかの魂を探した後、MicrosoftはUIフレームワークから最新のアプリフレームワークを解きほぐすことに決めました。

WinUI 3.0は両方の長所を備えている必要があり、言語プロジェクション、最新のコーディング標準、およびモバイルの使いやすさの恩恵を受ける最新のAPIにアクセスできます。ただし、アプリが安全性は低くても強力なWin32および.NETランタイムを使用できるようにします。

もちろん、Win32アクセスに依存することで、実行するプラットフォームが制限されます。また、今後数年間で市場がどこに移動するかは誰にもわかりません。

同じ古い根拠や不満を無視する代わりに、このコミュニティを使用して、開発者が今後何を望んでいるのかを尋ね、プロジェクトを前進させない方法で非難したり怒鳴ったりしないようにすることをお勧めします。

mdtauk 2020年01月20日

👍8

@mdtaukは書いた：

彼らは市場の力のためにモバイル市場から追い出されました。

さまざまなUWP / WinRTスタッフは、何が起こったのかをよりよく感じるために、その説明を非常に信じたいと考えています。私はその説明を信じていません。 UWPは次の理由で失敗したと思います。

管理ミス、および
UWPの準備ができておらず、プライムタイムの準備ができていないという印象のために、アプリ開発者がアプリのUWPバージョンを永続的に延期するという問題に対処できなかった。
非生産的な古いソフトウェアエンジニアリング技術の過度の使用、および
大多数のアプリ開発者の信頼を勝ち取ることの失敗、そして
Javaの代わりにJavaScriptの使用を促進するなど、UWPをばかげたように見せたのは、スクリプト言語とプログラミング言語の違いを認識できなかったことを意味します。

悲しいことに、管理ミスがUWPの失敗の主な理由であることを考えると、「管理されていない」という言葉が実際に失敗の理由を要約しているため、UWPが管理されていないコードで記述されているのは皮肉です。ソースコードとプロジェクト管理の両方の管理ミスです。

@jtorjoは書いた：

ネイティブ、「。netネイティブにコンパイル」のコンテキストでは、私は良いことだと思います

同意します。違いは、ネイティブコードの自動生成と手動生成にあります。ネイティブコードがコンパイラまたはツールによって自動的に生成される場合、それは通常は良いことですが、ネイティブソースコードが手動で記述されたソースコードの場合、生産性、機能セット、および信頼性が大幅に低下します。

WPF開発の時間枠とWinUI開発の時間枠を比較すると、WinUIは同じものの多くを再利用するため、WinUIはWPFよりも開発が簡単/高速であるはずでしたが、WPFの開発ははるかに高速でした（生産性がはるかに優れています）。 WPF用に_すでに_作成された概念。残念ながら、Microsoftは、独自の以前の見解と矛盾し、独自の生産性を妨害し、アプリ開発者がUWPアプリ開発を永久に延期することになった、古いソフトウェアエンジニアリング手法の過度の使用に従事することを選択しました。

過去の過ちを解決するために今何ができるでしょうか？ UWPの失敗につながったのと同じ間違いを繰り返すのをやめてください。何も悪いことが起こらなかったかのように続けないでください。ここでは、例としてDataGridを使用します。DataGridをさらに遅らせる代わりに、 DataGridに新しい機能を追加します。ネイティブコードへの無用な手動の書き換え/変換を行って、DataGridを8年以上延期しないでください。

エンドユーザーは、DataGridがマネージコードで記述されているかアンマネージコードで記述されているかを気にする必要がなく、それらの用語が何を意味するのかわからないため、マネージコードをそのままにして、 DataGridの機能/特徴。 UWPで手動で記述されたネイティブコードの量はすでに悲惨な状況です。それでは、Win16 / 32とCOMに基づいて、さらに多くのネイティブコードとさらに古いコードを記述して、状況をさらに悪化させるのはなぜですか。

廃止されたコードをすべて破棄することはできないと理解していますが、状況を悪化させるのをやめることはできます。つまり、さらにアンティークなネイティブコードの記述をやめます。今後、すべての新しいコード/プロジェクトは最新のソフトウェアエンジニアリング技術を使用して作成されるというポリシーを作成します。 DataGridなどの既存のマネージコードをダウングレードしないでください。

verelpode 2020年01月20日

UWPファイルシステムはまだアルファ版です
@jtorjoや他の人々は、UWPのファイルシステムAPIのパフォーマンスの問題について言及しています。パフォーマンスは、フィーチャーコンプリートのベータ版として説明するのに必要なレベルを下回っています。 [...]

これについては前に説明しましたが、もう一度説明します。StorageFolder/ StorageFile APIは、私が見た中で最悪のAPIの1つです。私たちは21世紀を迎えています。「ああ、お願いします、これにアクセスできますか？そしてそれにアクセスできますか？それからそれらを素晴らしいFuturesAccessListに追加しますか？」と尋ねる必要があります。

また、ファイルのサイズなどの基本的なプロパティを非同期で要求する必要がありますか？私はこれがどんな論理的根拠を持っていたのかは気にしませんが、今のところ現実とは接触していません。

jtorjo 2020年01月20日

これらの賭けは完全には報われていませんが、最新のアプリ配信とセキュリティモデルの理想は称賛に値する目標です。

全くもって同じ意見です...

[....]もちろん、Win32アクセスに依存することで、実行するプラットフォームが制限されます。また、今後数年間で市場がどこに移動するかは誰にもわかりません。 [...]

私は完全に同意しますが、将来を考えすぎることも苦痛になる可能性があります...
つまり、Win32へのアクセスを最初から制限すると、ライブラリの移植はほとんど「ノーゴー」になるため、将来はもちろん、現在もありません。

Win32コードも使用できるようにすることで、別の（今後の）プラットフォームに移植できない可能性がありますが、少なくとも今日のコードはあります。そして明日はまた別の日になるでしょう。そこに着いたら、本当に必要な場合にコードを移植する方法を考えます。

しかし、私は選択に与えられるべきことをします、そして私はリスクを理解します。

同じ古い根拠や不満を無視する代わりに、このコミュニティを使用して、開発者が今後何を望んでいるのかを尋ね、プロジェクトを前進させない方法で非難したり怒鳴ったりしないようにすることをお勧めします。

これが私を対象としたものなのか、それとも何かを対象としたものなのかはわかりませんが、私は英語を母国語とはしていません。そうは言っても、私は間違いなくこのプロジェクトを前進させたいと思っていますが、今日、私たちが展開するのを妨げるいくつかの問題に対処することが重要だと思います。

jtorjo 2020年01月20日

同じ古い根拠や不満を無視する代わりに、このコミュニティを使用して、開発者が今後何を望んでいるのかを尋ね、プロジェクトを前進させない方法で非難したり怒鳴ったりしないようにすることをお勧めします。
これが私を対象としたものなのか、それとも何かを対象としたものなのかはわかりませんが、私は英語を母国語とはしていません。そうは言っても、私は間違いなくこのプロジェクトを前進させたいと思っていますが、今日、私たちが展開するのを妨げるいくつかの問題に対処することが重要だと思います。
私は誰もターゲットにしていませんが、議論のタイトルは少し否定的であり、侮辱や非難に巻き込まれた場合、人々は正当な問題に対応して対処する傾向がありません。

また、Win32 /.NETアプリフレームワークがWinUI3.0に付属することもわかりました。これまで、WinRTであると批判する意味はほとんどありません。 😁

mdtauk 2020年01月20日

@jtorjo

私たちは21世紀を迎えています。「ああ、お願いします、これにアクセスできますか？そしてそれにアクセスできますか？それからそれらを素晴らしいFuturesAccessListに追加しますか？」と尋ねる必要があります。

アプリがユーザーに尋ねなければならないという事実は、私の意見では正しい方向への一歩です。 WinformsやWPFアプリとは異なり、アプリはすべてのファイルを単純にスキャンすることはできず、アクセスできるフォルダーを制御できるという事実は、セキュリティ上非常に重要です。アプリがユーザーを保護するためにアクセスできるリソースを制限するのは悪いことだと思うなら、それはあなたの見解だと思いますが、すべてのアプリが私のファイルで望むことを実行することを望んでいません。

また、ファイルのサイズなどの基本的なプロパティを非同期で要求する必要がありますか？私はこれがどんな論理的根拠を持っていたのかは気にしませんが、今のところ現実とは接触していません。

UXポイントから発生する可能性のある最悪の事態は、開発者がディスク操作に少し時間がかかる可能性があることを忘れているためにアプリが応答しなくなることであるため、UIスレッドをブロックしてはならないという理論的根拠があったと思います。 awaitを使用すると、問題を回避でき、ある時点でUIスレッドのブロックを解除する必要があります。（少なくとも、それが私がasync awaitを理解する方法です）。

@mdtaukが正しく指摘しているように、ディスカッションのタイトルは確かに少し否定的であり、同じ古い不満を繰り返し続けるのではなく、そのようなディスカッションを使用して、そのような問題を解決するためのアイデアを考え出す必要があります。

私たちは皆、マイクロソフトのオープンソースの行動規範を遵守し、専門的な議論を続け、存在するかどうかに関係なくすべての人に敬意を払うことを心に留めておくべきだと思います。

https://opensource.microsoft.com/codeofconduct/

chingucoding 2020年01月20日

👍2

アプリがユーザーに尋ねなければならないという事実は、私の意見では正しい方向への一歩です。 WinformsやWPFアプリとは異なり、アプリはすべてのファイルを単純にスキャンすることはできず、アクセスできるフォルダーを制御できるという事実は、セキュリティ上非常に重要です。アプリがユーザーを保護するためにアクセスできるリソースを制限するのは悪いことだと思うなら、それはあなたの見解だと思いますが、すべてのアプリが私のファイルで望むことを実行することを望んでいません。

そのため、WPFアプリと比較して大きな欠点から始めます。それは一つのことです-もう一つのことは

私はすでにインストール時にそれを求めています。
ユーザーが注意を払わなくても、Windowsは再びユーザーに「このアプリはあなたのファイルへのアクセスを望んでいます」と表示し、ユーザーは「はい/いいえ」と言うことができます。私はそれで完全に大丈夫でしょう。しかし、これは起こっていることから遠いです。

また、ファイルのサイズなどの基本的なプロパティを非同期で要求する必要がありますか？私はこれがどんな論理的根拠を持っていたのかは気にしませんが、今のところ現実とは接触していません。
UXポイントから発生する可能性のある最悪の事態は、開発者が忘れたためにアプリが応答しなくなることであるため、UIスレッドをブロックしてはならないというのが理論的根拠だったと思います。

ファイルサイズはプリフェッチする必要があります（最終アクセス日/最終書き込み日と同じ）-ファイルのクエリを実行するときにプリフェッチする必要があるほど重要です。

@mdtaukが正しく指摘しているように、ディスカッションのタイトルは確かに少し否定的であり、同じ古い不満を繰り返し続けるのではなく、そのようなディスカッションを使用して、そのような問題を解決するためのアイデアを考え出す必要があります。

私はこれらを完全に解決したいと思っています。

私たちは皆、マイクロソフトのオープンソースの行動規範を遵守し、専門的な議論を続け、存在するかどうかに関係なくすべての人に敬意を払うことを心に留めておくべきだと思います。

実際にこれらの質問をする場所があり、WinRTが他の場所でフィードバックを聞くことができれば、この議論はここでは起こりませんでした。

jtorjo 2020年01月20日

私は誰もターゲットにしていませんが、議論のタイトルは少し否定的であり、侮辱や非難に巻き込まれた場合、人々は正当な問題に対応して対処する傾向がありません。

WinRTの問題についてフィードバックを提供する場所が他にあった場合、これは少し否定的であることに同意します。

また、Win32 /.NETアプリフレームワークがWinUI3.0に付属することもわかりました。これまで、WinRTであると批判する意味はほとんどありません。 😁

正直なところ、私は本当にこれが事実であることを願っています。私は確かにこれらの問題が解決されるのを待ちます、そして個人的にその非サンドボックスプラットフォームが利用可能になるのを待つことはできません。しかしそれまで、私はまだアプリに取り組んでおり、最初に概説した問題に直面しています。

jtorjo 2020年01月20日

そのため、WPFアプリと比較して大きな欠点から始めます。それは一つのことです-もう一つのことは

明確にするために、アプリがすべてのファイルにアクセスすることを拒否するという選択を残すことは、あなたの意見では不利ですか？
私たち開発者は、ユーザーに反対するのではなく、ユーザーのためにソフトウェアを開発する必要があります。そして、私の意見では、アプリがどのデータを表示するかをユーザーに選択させないことは、ユーザーにとってセキュリティ上の不利益になります。

私はすでにインストール時にそれを求めています。

「broadFileSystemAccess」機能を意味しますか？私の意見では、この機能を持つ正当な理由があるアプリはほとんどありません。（ @kmgallahanがすでに指摘しているように）
日常的に使用しているすべてのアプリを見てください。そのうちの何人が常にすべてのファイルにアクセスする必要がありますか？あるとしても、おそらくそれほど多くはありません。

あなたが最初のコメントで言ったように：

ユーザーは上記を喜んでやってくれると思いますか？いいえ、そうはなりません-実際、79.8％はそうしません（私のAppCenterデータはこれをバックアップします）。

ユーザーがこれを行うことに満足していない理由はおそらくあると思います（これはユーザーが変更しなければならないセキュリティ設定であるという事実に加えて）。

ただし、すべてのファイルにアクセスする必要があるすべてのビジネスケースを知っているとは限らないので、何かあれば喜んで聞いています。結局のところ、私たちは戦うためにここにいるのではなく、お互いの視点を豊かにするためにここにいます（願わくば）😅

編集：

ファイルサイズはプリフェッチする必要があります（最終アクセス日/最終書き込み日と同じ）-ファイルのクエリを実行するときにプリフェッチする必要があるほど重要です。

そうそう、そうです、それらのいくつかは間違いなく事前にフェッチされるべきです。これは私たちの開発者にとってやや不便であることに同意します。

実際にこれらの質問をする場所があり、WinRTが他の場所でフィードバックを聞くことができれば、この議論はここでは起こりませんでした。

公式にはフィードバックハブはそのためのものです（私は思います）が、はい、それはいつか少し反応しなくなったように感じます。うまくいけば、フィードバックハブが改善されます。私が見る限り、彼らはすでに時間の経過とともにそれにいくつかの変更を加えているので、これもうまくいけば変わると思います。

chingucoding 2020年01月20日

@ Felix-Dev

こちらが.NET5の発表記事です

リンクしてくれてありがとう。私は特にこの部分が面白いと思いました、そしてこれは前向きなニュースだと思います：

「Javaの相互運用性は、すべてのプラットフォームで利用できるようになります。

そのWebページの最後にあるコメントにもJavaに関する議論が少しあり、RichLanderが双方向の相互運用を確認しています。私はこれを、マイクロソフトが現実との接触を

好むと好まざるとにかかわらず、目を覚まして状況の現実を認識する必要があります。マーケットリーダーはAndroidであり、Javaアプリの開発に重点を置いています。 JavaとC＃はマネージコードを意味します。マイクロソフトは、マネージコードに対する見方を覆したときに、非常にコストのかかる間違いを犯しました。

私はJavaがあまり好きではありませんが、AndroidのJava技術は、Microsoftが16ビットと32ビットのポインターなどの旧式のWin16プログラミング技術を使用してWebView2を開発している不格好な古い方法よりもはるかに優れていることは明らかです。、および最新の例外処理などの代わりにHRESULT 。WebView2はLPCWSTRを使用し、 Lは「長いポインタ」を意味し、16ビットではなく32ビットのポインタを意味します。 Win16の「短い」ポインタ。 Wは、8ビットASCII / ANSI文字ではなく、Unicode（UTF-16）を意味する「ワイド文字」を意味します。それに比べて、AndroidでのJavaの使用は、Microsoftの一部の部門が行っていることよりもはるかに専門的で、現代的で、信頼を刺激します。

したがって、前向きなことに、MicrosoftがJavaをサポートすると聞いて本当に素晴らしいニュースです（個人的にはJavaよりもC＃の方が好きですが）。 Androidアプリの開発者は、信頼性の高いJava相互運用機能がリリースされるとすぐに、Windowsへの関心を高めるでしょう。

verelpode 2020年01月20日

また、Win32 /.NETアプリフレームワークがWinUI3.0に付属することもわかりました。これまで、WinRTであると批判する意味はほとんどありません。 😁

未来は明るいです、私は私が見るものがWinUIで開発されているのが大好きです。
過去はかなり暗いものでした。9億台のデバイスを搭載したプラットフォームでは、UWPの普及率が低いことを防御するのは困難です。編集：過去は私たちが学ぶことができる唯一の場所なので、議論することが重要です。
現在がこのスレッドの要点であり、対処されていないと思います。誰かが今日、開発に1〜1。5年かかる重要なアプリを開始したい場合、どのような正直なアドバイスを与えることができますか？私の答えは次のとおりです。WinUIを試して、dotnet Coreでライブラリを作成し、WinUI3.0が実際にアプリの作成を開始するのを待ちます。とにかくアプリからUWPを破棄したいので、UWPを気にしないでください。9億のプラットフォームは十分に大きいため、異なるプラットフォームはおそらく必要ありません。現在についての質問は些細なことではありません、ビジネス上の決定は今日なされる必要があります。

言われていないことですが、実際に起こっていることは、UWPと最新のUIがwin32に拡張されていないことですが、実際にはUWPはスタックからリファクタリングされています。 dotnet standard2とdotnetcore 3のパワー、およびそれで利用可能なすべてのライブラリを使用できるのに、なぜ誰もがUWPを扱いたいと思うのでしょうか。

UWPで導入されたサンドボックスやその他の優れたアイデアについて：それらは優れたアイデアでしたが、はるかにうまく実行できたはずです。彼らが戻ってきて、サンドボックスへのオプトインまたはUWPと同様の状態管理へのオプトインの可能性があることを願っています。開発者としてユーザーにサービスを提供したいのですが、UWPでは、プラットフォームに含める必要のある問題として脅かされていました。

どのような正直なアドバイスを与えることができますか？待って？

AndrewPawlowski 2020年01月20日

😕1 👍1

@AndrewPawlowski UWPとサンドボックスが機能しないと判断した場合は、WinUI 3がリリースされるまで、MSIXパッケージのWPFアプリを作成することをお勧めします。すでにWindows10専用APIを呼び出して、ユーザーに最新のインストール/アンインストールエクスペリエンスを提供し、通常、Windows 10 APIサーフェスから好きなものと嫌いなものを選択できます（つまり、Windows 10 Shell APIの使用を開始できます）。一部のWinRTAPIは、過去のwin32の方法と比較して、実際に作業するのが楽しいものです。また、一部のシナリオは、純粋なUWPではなくDesktopBridgeで最適に実行されると私は信じています。適切な例：ログイン時に自動起動するアプリを登録します。UWPとDesktopBridgeの動作の比較については、この投稿を参照してください。 DesktopBridgeの場合でも、最終的にはユーザーを制御できますが、ログでの開始を有効にするときに、ユーザーが常に2回（最初にアプリのトグル、次に確認を求めるシステムプロンプト）尋ねられることはありません。アプリで。

残念ながら、WPF APIの多くの部分は、UWP UI APIと比較した場合、実際にその年齢を示しているため、（少なくとも）あと数か月はそれと一緒に暮らす必要があります。利用可能な多くのWPFツールキットはこの事実を軽減しますが、Windowsデスクトップアプリのネイティブなルックアンドフィール（および最新のXAML開発エクスペリエンス！）が本当に必要な場合は、UWP UI API（および後でWinUI3 API）。つまり、後でWinUIのWPF UIコードの一部を再利用できたとしても、UIの最新化はかなり大きな作業項目になると私は信じています。

これが、WinUI 3が出荷され、UWPが選択できない場合に、現在私が目にしているネイティブWindowsアプリ開発の状態です。

Felix-Dev 2020年01月20日

👍1

@AndrewPawlowski

未来は明るいです、私は私が見るものがWinUIで開発されているのが大好きです。

同意する

過去はかなり暗いものでした。9億台のデバイスを搭載したプラットフォームでは、UWPの普及率が低いことを防御するのは困難です。編集：過去は私たちが学ぶことができる唯一の場所なので、議論することが重要です。
現在がこのスレッドの要点であり、対処されていないと思います。誰かが今日、開発に1〜1。5年かかる重要なアプリを開始したい場合、どのような正直なアドバイスを与えることができますか？私の答えは次のとおりです。WinUIを試して、dotnet Coreでライブラリを作成し、WinUI3.0が実際にアプリの作成を開始するのを待ちます。 UWPを気にしないでください。

当初の考えは同じでしたが、待ちきれませんでした…。

UWPで導入されたサンドボックスやその他の優れたアイデアについて：それらは優れたアイデアでしたが、はるかにうまく実行できたはずです。

100％同意しました

jtorjo 2020年01月20日

ただし、すべてのファイルにアクセスする必要があるすべてのビジネスケースを知っているとは限らないので、何かあれば喜んで聞いています。結局のところ、私たちは戦うためにここにいるのではなく、お互いの視点を豊かにするためにここにいます（願わくば）😅

プレビューしたい場所ならどこでも、ファイルへの高速アクセスが必要になります。私の場合、フォルダをプレビューして、写真/ビデオがどこにあるかをユーザーに視覚的に示したいと思います。ビデオの場合は、ユーザーがビデオを選択する前にプレビューしてもらいたいと思います。重要なのは、ファイルピッカーはかなり標準以下のエクスペリエンスを提供するということです。私はそれを充実させたかったのです。

公式にはフィードバックハブはそのためのものです（私は思います）が、はい、それはいつか少し反応しなくなったように感じます。うまくいけば、フィードバックハブが改善されます。私が見る限り、彼らはすでに時間の経過とともにそれにいくつかの変更を加えているので、これもうまくいけば変わると思います（^∇^）

個人的に私はフィードバックハブが好きではありません-それは他の問題の中でも特に不特定です。

jtorjo 2020年01月20日

WinRTAPIの@ jtorjo @ chingucodingフィードバックハブは、まもなくMicrosoft Q＆Aに置き換えられるか、ペアリングされる可能性があります。このコミットを確認してください： //github.com/MicrosoftDocs/winrt-api/commit/efcc4e041122e8a816a12c0581199c2f36ba36fc

Chigusaがそこで言及されているように見えます：

うまくいけば、 3つの異なるフィードバックプラットフォームで終わることはありません😆

Felix-Dev 2020年01月20日

これはUWPに関するディスカッションなので、機能リクエストを宣伝できます。ファイルタイプの関連付けがなくても、ファイルエクスプローラーの統合でコンテキストメニューの動詞を許可しますhttps://aka.ms/AA71n2tところで。 https://aka.ms/AA6rmrk （ただし、カテゴリが間違っています。誰かがこれを修正できる可能性がありますか？）

機能リクエストの適切なソースは次のとおりです。
https://web.archive.org/web/20161221051552/https：//wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
このユーザーボイスのスナップショットはかなり古い（2016年）のは残念です。私は次のようなものがあったことを覚えています：

カメラ、場所、起動時にアプリを起動するときに動作するように、broadFileSystemAccessリクエストの動作を調整します...
自動。印刷（私が覚えている限り、現在はIoT上のPOSでのみサポートされています）
印刷をより構成可能にする

mfe- 2020年01月20日

@jtorjo

プレビューしたい場所ならどこでも、ファイルへの高速アクセスが必要になります。私の場合、フォルダをプレビューして、写真/ビデオがどこにあるかをユーザーに視覚的に示したいと思います。ビデオの場合は、ユーザーがビデオを選択する前にプレビューしてもらいたいと思います。重要なのは、ファイルピッカーはかなり標準以下のエクスペリエンスを提供するということです。私はそれを充実させたかったのです。

そのためには、まずユーザーにアプリを使用するフォルダーを選択させると思います。結局のところ、ユーザーは自分のビデオをどこに保存したかを最もよく知っています。

それ以外の場合は、以下を確認することをお勧めします。
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

しかし、正直なところ、その場合、broadFileSystemAccessがどのように役立つかはわかりません。（ユーザーとは異なり）ファイルが正確にどこにあるかを確認することはできません。しかし、私はあなたのアプリのアイデアを正しく理解していないかもしれません。

@ Felix-Dev
情報をありがとう、WinRTフィードバックが動くかもしれないことを知りませんでした。

うまくいけば、3つの異なるフィードバックプラットフォームで終わることはありません😆

ハハはい、うまくいけばそうではありません！

chingucoding 2020年01月20日

@ jtorjo -WPFからUWPへのアプリの移植をキャンセルすることを検討

WinRTの開始から8年間、実際にWinRTやUWPアプリをユーザーに提供したことはありません。代わりに、ソフトウェアのWPFバージョンを引き続き使用する多くの更新プログラムを提供しました。ユーザーは、WPF、WinUI、UWPなどの技術的な詳細を気にせず、アプリの動作と機能を気にするため、これについての不満はありません。また、WPFアプリには多数のGUIの最新化が含まれているため、ユーザーは古いGUIについて不満を持っていません。

@AndrewPawlowskiは「

WinUI 3をUWPから分離することは大きな助けになりますが、完全な解決策ではないと思います。 WinUI 3は、WinUIの生産性の低さ/開発のペースの遅さに対処していません。WPFはWinUIよりも困難でしたが、WPFはWinUIよりもはるかに速く開発されました。

WinUIチームは、WinUI 3がオープンソースになるとペースが速くなると言っていますが、個人的にはWinUI3用のC ++ / CX、C ++ / WinRT、Win16 / 32、またはCOMの寄稿は書きません。私のキャリアは数十年前にWin16 / Win32で始まりましたが、Win32は悪夢でした。私は、このような古くて問題のあるプログラミング手法に戻るつもりはありません。何年にもわたって、ソフトウェアエンジニアリングのスキルを最新の状態に保ち、C＃と.NET Frameworkに切り替えました。これは大きな改善とメリットであり、古いWin16 / 32の悪夢に戻ることはありません。日と大量の手動で書かれたネイティブコード。

@AndrewPawlowskiは書いた：

どのような正直なアドバイスを与えることができますか？待って？

それは答えるのが本当に難しい質問です。一方で、WinUI 3を待ちますが、他方で、WinUI 3は、8年前にWinRTによって開始された大きな問題の完全な解決策ではありません。 WinUI 3は、役立つ部分的な解決策です。

verelpode 2020年01月20日

Igniteからの素晴らしいビデオ： https ：

ここでの議論の多くは、WinRTの目的に疑問を投げかけていると思います。開発者もユーザーも同様に、WinUI3と.NET5.0が異なるテクノロジー間の簡単な相互運用を可能にした後、それがどのような役割を果たすのか疑問に思っています。言うまでもなく、サンドボックス化されたアプリモデルとクラシックなアプリモデルを選択する最終的な機能。

新しいWinRTAPIを作成することは、Microsoftが社内で行う方が簡単だと思います。これが、APIレイヤーの革新のほとんどがWinRT内で行われる前に何度も述べてきた理由を説明しています。これは、新しい最新のWindowsアプリケーションの場合、WinRTを使用するのが理にかなっていることを意味します。これは、新しいフォームファクターに伴う新しいエクスペリエンスとの最新かつ最高の統合が行われるためです。 WinRTは、Windows上の.NETアプリで点灯する特定のユニバーサルAPIのセットとしてのみ意図されています。

そうは言っても、UWPデスクトップ拡張機能パックが既存のWindowsシェルとの統合機能が優れていれば、ユニバーサルアプリの価値が高まることには誰もが同意すると思います。

誰が知っているか、マイクロソフトは最終的にWindowsエクスプローラーシェルをWindows 10Xなどにある新しいコンポーザブルシェル（CShell）に置き換える計画があるかもしれません。Twitterの専門家はまた、Windowsにある新しいUDK（Undocked Development Kit）を発見しました。将来的には、この新しいシェルとの統合が改善されます。

duke7553 2020年01月20日

👍1

@AndrewPawlowski

9億のプラットフォームは十分に大きいので、おそらく異なるプラットフォームは必要ありません。

意味はわかりますが、UWPと.NETはもはやこれらの相互に排他的なものではないことを理解する必要があります。したがって、ユニバーサル機能を使用してアプリを起動することが理にかなっている場合は、WinRTの一部を理解することに投資する必要があります。

私は逸脱します。純粋なUWPアプリモデルを使用してWindowsファイルエクスプローラーの競合製品を構築した人として、WinUI3は十分な速度で実現できません。近い将来、ユニバーサル機能を使用するか、「9億人のユーザー」を使用するかを選択する必要はありません😀

duke7553 2020年01月20日

@jtorjoタイトルを、ネガティブに感じられないタイトルに変更することをお勧めします。そうすれば、より多くの人がここに入力を提供します。
おそらく「WinRTに価値を付加する機会」

duke7553 2020年01月20日

@verelpode

@ jtorjo -WPFからUWPへのアプリの移植をキャンセルすることを検討

私はこれについて長く懸命に考えました-これが私がやりたかったことです。しかし、私は本当にwin2d（またはもっと正確に言えば、Direct2Dの優れたラッパー）が必要なので、それを行うことはできません。 ShapDX（Direct2Dの別のラッパー）ははるかに複雑に見えたので、win2d（UWP）を使用することにしました。したがって、すべてをUWPに移植します。

jtorjo 2020年01月21日

そのためには、まずユーザーにアプリを使用するフォルダーを選択させると思います。結局のところ、ユーザーは自分のビデオをどこに保存したかを最もよく知っています。

あなたは本当にあなたの人生をそれに賭けていますか？私はそうは思いません-明らかに、あなたが上級ユーザーなら、あなたはめちゃくちゃ組織化されていて、あらゆるものがどこにあるかを知っているかもしれません。さもないと....

そして、あなた（ユーザー）がどういうわけか写真/ビデオを新しいフォルダーにコピーするときはいつでも、それも含めるように私のアプリに伝えることを忘れないでください...

「素晴らしい」FutureAccessListは言うまでもありません-実際には指定されていません->フォルダーを追加した場合、そのすべてのサブフォルダーにアプリからアクセスできますか？

また、FutureAccessListに何かを追加した場合、そこから取得する必要がありますか、それともGetFolderFromPathAsync / GetFileFromPathAsyncで取得できますか（前者の場合、崖から飛び降りたい）？

また、FutureAccessList.AddOrReplaceを使用し、ファイルのパスをトークンとして使用すると、例外が発生することをご存知ですか？どれほど思慮深い...（説明のどこにもありません）

jtorjo 2020年01月21日

WinUI3と.NETCoreは将来のオプションになるでしょう-UWPのサンドボックスなしの組み合わせは、WPFと同じように機能しますが、新しいXAMLコントロール、ビジュアルレイヤー、および単純なWinRTAPIアクセスを使用します。

mdtauk 2020年01月21日

そのためには、まずユーザーにアプリを使用するフォルダーを選択させると思います。結局のところ、ユーザーは自分のビデオをどこに保存したかを最もよく知っています。

あなたは本当にあなたの人生をそれに賭けていますか？私はそうは思いません-明らかに、あなたが上級ユーザーなら、あなたはめちゃくちゃ組織化されていて、あらゆるものがどこにあるかを知っているかもしれません。さもないと....

ユーザーが自分の動画をどこに保存したかわからない場合、アプリは何をすべきでしょうか？システム内のすべてのファイルをスキャンします。最速のソフトウェアでも数時間かかる場合がありますか？少なくとも私にとって、これは良い経験ではないようです。結局のところ、アプリがビデオで何かをしたいユーザーをターゲットにしている場合、ユーザーはすでにどこかにビデオがあることを知っているスネーゼである程度「組織化」されています。しかし、繰り返しになりますが、アプリや特定のビジネスケースを実際に知らなくても、私の考えだけです。

そして、あなた（ユーザー）がどういうわけか写真/ビデオを新しいフォルダーにコピーするときはいつでも、それも含めるように私のアプリに伝えることを忘れないでください...

親ディレクトリへのアクセス権があれば、将来の子フォルダにもアクセスできると思います（100％確信はありませんが）。

また、FutureAccessList.AddOrReplaceを使用し、ファイルのパスをトークンとして使用すると、例外が発生することをご存知ですか？どれほど思慮深い...（説明のどこにもありません）

それは奇妙です、これは間違いなく文書化されるべきものです！

個人的には、「broadFileSystemAccess」を要求するアプリの多くはそれを必要としないため、私は実際にはアプリのファンではありません。理にかなっている場合もあるかもしれませんが（ファイルエクスプローラーを作成するなど）、一部のフォルダーにアクセスする必要がある場合は、「すべてのファイルへのアクセスを許可してください」と言ってはいけません。特にそのフォルダ。

しかし、多分私はそのようなための十分なビジネスケースを知りません。もっとあれば聞いてみたいです！

chingucoding 2020年01月23日

しかし、多分私はそのようなための十分なビジネスケースを知りません。もっとあれば聞いてみたいです！

（解凍）圧縮ツールのようなツールとユーティリティソフトウェア。現在のファイルが配置されているのと同じディレクトリに圧縮ファイルを抽出する場合、Windowsエクスプローラーのコンテキストメニューからアプリが呼び出されたときに、選択したファイルへの書き込みアクセス権しか取得できませんでした。したがって、（非圧縮ファイル用に）新しいファイルまたはディレクトリを作成することはできません。
- ユーザーがファイルをuwpアプリにドラッグした場合、それらのファイルへの書き込みアクセス権はありません。
  https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

mfe- 2020年01月23日

（解凍）圧縮ツールのように。現在のファイルが配置されているのと同じディレクトリに圧縮ファイルを抽出する場合、Windowsエクスプローラーのコンテキストメニューからアプリが呼び出されたときに、選択したファイルへの書き込みアクセス権しか取得できませんでした。したがって、（非圧縮ファイル用に）新しいファイルまたはディレクトリを作成することはできません。

1つのファイルを右クリックしたときにフォルダ全体にアクセスできるかどうかは非常に議論の余地があると思います。 tbhですが、通常、バックアップまたはダウンロード/アップロードなどの「交換」にのみ必要なため、圧縮/解凍時に別のフォルダを指定します。したがって、私にとっては、ファイルを保存する場所を正確に指定する必要があります。しかし、これはユーザーの選択によっては有効なユースケースになる可能性があります😅

ユーザーがファイルをuwpアプリにドラッグした場合、それらのファイルへの書き込みアクセス権はありません。
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

それは、ユーザーと開発者にとって少し複雑すぎるように思えます。少なくとも、削除されたファイルへの書き込みアクセス権を取得できると期待していました。私の意見では、これは開発者にとって不必要な制約にすぎません。

少なくとも日常のアプリの使用では、ファイルをGitHubのコメントにドロップするだけです。他のすべてのケースでは、ダブルクリックまたは右クリックするだけですが、それがうまくいかない場合もあります。結局のところ、すべてのファイルにアクセスすることが理にかなっている場合がいくつかあると思います。

chingucoding 2020年01月23日

ユーザーが自分の動画をどこに保存したかわからない場合、アプリは何をすべきでしょうか？システム内のすべてのファイルをスキャンします。最速のソフトウェアでも数時間かかる場合がありますか？ ..。

明らかに多くの可能性があります。そのうちの1つは、ユーザーがフォルダーを展開したときにプレビューすることです。そのため、写真やビデオが含まれているフォルダーと含まれていないフォルダーを簡単に確認できます。 Windowsで許可された場合、私のアプリが実際に行うことの1つ

個人的には、「broadFileSystemAccess」を要求するアプリの多くはそれを必要としないため、私は実際にはアプリのファンではありません。

私は関係ありません。 WinRTのサンドボックスのファイルシステム保護モデルは、現実とはかけ離れています。これは、誰かが「モバイルファースト」という素晴らしいマントラから取ったものであり、デスクトップには当てはまりません。

実際、ファイル/フォルダーをサンドボックス化するためのはるかに賢い方法は、保護するファイル/フォルダーをユーザーが決定できるようにすることです。これを行うには、非常に簡単な方法が必要です（たとえば、ファイルエクスプローラーで右クリックコマンドを使用するなど）。。

これは、デフォルトですべてをブロックし、ユーザーが誤って機密ファイルへのアクセスを許可してしまうのとは対照的です。

ここで率直に言ってみましょう-些細なことではないアプリは、真空の中には存在しません。

jtorjo 2020年01月24日

明らかに多くの可能性があります。そのうちの1つは、ユーザーがフォルダーを展開したときにプレビューすることです。そのため、写真やビデオが含まれているフォルダーと含まれていないフォルダーを簡単に確認できます。 Windowsで許可された場合、私のアプリが実際に行うことの1つ

はい、それは可能性です。しかし、いつフォルダをスキャンするのでしょうか。また、ユーザーがアプリで正確に展開できるフォルダーはどれですか？

私は関係ありません。

ここで正確に何を言おうとしているのですか？

実際、ファイル/フォルダーをサンドボックス化するためのはるかに賢い方法は、保護するファイル/フォルダーをユーザーが決定できるようにすることです。これを行うには、非常に簡単な方法が必要です（たとえば、ファイルエクスプローラーで右クリックコマンドを使用するなど）。。ユーザーは、どのドキュメント/ファイルが機密であるかを明確に把握し、それらを保護します。

この全体的なアクセス保護は、「機密」ファイルだけでなく、一般的なプライバシー、たとえば構成ファイル（ユーザーには表示されないフォルダーに隠されている）やインストールされているプログラムだけだと思います。これらは、すべてのプログラム、特にあなたがそれらを呼んだ「些細なアプリ」にアクセスできるようにしたくない情報です。

また、実際の例えもあります。seifについて考えてみてください。

はい、金庫の中から物を見ることができます。しかし、これはあなたがあなたのアパートや家への鍵を持っているという事実を変えるものではありません。しかし、すべてのプログラムが金庫の中以外のすべてにアクセスできると言うのは、貴重品用の金庫があるので、フラットのドアは必要ないと言うようなものです。

これは、デフォルトですべてをブロックし、ユーザーが誤って機密ファイルへのアクセスを許可してしまうのとは対照的です。

この間違いはどちらの場合にも発生する可能性がありますが、誤って機密ファイルへのアクセスを許可するよりも、機密ファイルのロックを忘れる可能性が高いと思います。

ここで率直に言ってみましょう-些細なことではないアプリは、真空の中には存在しません。どこか（入力）からデータを取得し、どこかに出力する必要があります。多くの場合、入力と出力はファイルです。他のアプリなどと相互運用する必要があります。そして、WinRTを使用すると、ユーザーに提供する優れたUIを設計することが不可能になります。

すばらしいUWPアプリがたくさんあるので、不可能だと言うのはここでは一筋縄ではいきません（残念ながら多くはありませんが）。

chingucoding 2020年01月25日

はい、それは可能性です。しかし、いつフォルダをスキャンするのでしょうか。また、ユーザーがアプリで正確に展開できるフォルダーはどれですか？

Windowsエクスプローラーの概念に精通していますか？あなたはフォルダまたはドライブを展開します-それは私がスキャンを開始するときです

この全体的なアクセス保護は、「機密」ファイルだけでなく、一般的なプライバシー、たとえば構成ファイル（ユーザーには表示されないフォルダーに隠されている）やインストールされているプログラムだけだと思います。これらは、すべてのプログラム、特にあなたがそれらを呼んだ「些細なアプリ」にアクセスできるようにしたくない情報です。

アプリがファイルを独自の「このアプリのみがアクセスできる」フォルダーに保持する場合、これは問題ではありません。

これは、デフォルトですべてをブロックし、ユーザーが誤って機密ファイルへのアクセスを許可してしまうのとは対照的です。
この間違いはどちらの場合にも発生する可能性がありますが、誤って機密ファイルへのアクセスを許可するよりも、機密ファイルのロックを忘れる可能性が高いと思います。

私は完全に同意しません-「機密」の全体的なポイントはあなたがそのファイルをロックしたくなるはずです。

すばらしいUWPアプリがたくさんあるので、不可能だと言うのはここでは一筋縄ではいきません（残念ながら多くはありませんが）。

あなたはここであなた自身と矛盾しています。しかし、すばらしいUWPアプリの広大さを詳しく見ていきましょう。

いいねの「豊富さ」に注目してください。これは、それを使用している人の数を示しているはずです。アップルストアとは対照的にしたかったのですが、アップルを持っていないのでできません。しかし、Androidを見てみましょう-Facebookには7000万以上のレビューがあります（Windowsの1353と比較して）。 Instagramには9300万以上のレビューがあります（ここでは1578と比較して）。そして、FbとInstagramの両方が実際にはUWPではなく電子アプリであるとほぼ確信しています。

jtorjo 2020年01月25日

Windowsエクスプローラーの概念に精通していますか？あなたはフォルダまたはドライブを展開します-それは私がスキャンを開始するときです

それで、フォルダ内のビデオファイルをプレビューするWindowsエクスプローラに似たものを構築していますか？

アプリがファイルを独自の「このアプリのみがアクセスできる」フォルダーに保持する場合、これは問題ではありません。

そのため、アプリは通常すべてのファイルにアクセスできる必要がありますが、一方で、一部のファイルとフォルダーはユーザーによってロックされ（ユーザーは「機密」ファイルのみを持ち、他のすべては自動的に機密ではないため）、一部のフォルダーはアプリのテーマ自体によってブロックされていますか？また、プログラムによって生成されたファイルを処理するアプリをプログラムしたい場合はどうすればよいですか？プログラムをバックアップできないため、すべてのバックアッププログラムが失敗しますか？それがどのように機能するかはよくわかりません。ここであなたの考えを誤解してしまった場合は申し訳ありません。

私は完全に同意しません-「機密」の全体的なポイントはあなたがそのファイルをロックしたくなるはずです。

では、私が機密として選択しないのは正確には何でしょうか？すべてのアプリに休日の写真を表示させたくありませんが、Photoshopで表示できるはずです。それで、彼らは秘密ですか？または、この機密の「フラグ」はプログラムのリストであり、一部のファイルは一部のアプリの機密ではありませんか？

あなたはここであなた自身と矛盾しています。

ええ、私の言い回しはそこにゴミでした。申し訳ありません。私は、うまく機能する優れた「重要な」アプリが確実に存在することを示したかったのです。

いいねの「豊富さ」に注目してください。これは、それを使用している人の数を示しているはずです。アップルストアとは対照的にしたかったのですが、アップルを持っていないのでできません。しかし、Androidを見てみましょう-Facebookには7000万以上のレビューがあります（Windowsの1353と比較して）。 Instagramには9300万以上のレビューがあります（ここでは1578と比較して）。そして、FbとInstagramの両方が実際にはUWPではなく電子アプリであるとほぼ確信しています。

これはUWPの問題ではなく、次の事実に問題があります。

人々は通常コメントを書く傾向がありません
iTunesストア/ GooglePlayストアはMicrosoftストアよりもはるかに古いです
Microsoft Storeはユーザーの間で好評でなく、うまく開始されませんでした
プラットフォーム限定のアプリではなくウェブサイトの開発を好むほとんどの企業

そして、FbとInstagramの両方が実際にはUWPではなく電子アプリであるとほぼ確信しています。

ウェブサイトとアプリの見た目が大きく異なるため、電子であるかどうかを判断するのは困難です。ダイアログがデフォルトのダイアログとほぼ同じように見えるという事実に基づいて、それらはUWPアプリである可能性があります。

chingucoding 2020年01月26日

それで、フォルダ内のビデオファイルをプレビューするWindowsエクスプローラに似たものを構築していますか？

これは私のアプリのウィザードの一部です。

そのため、アプリは通常すべてのファイルにアクセスできる必要がありますが、一方で、一部のファイルとフォルダーはユーザーによってロックされ（ユーザーは「機密」ファイルのみを持ち、他のすべては自動的に機密ではないため）、一部のフォルダーはアプリのテーマ自体によってブロックされていますか？また、プログラムによって生成されたファイルを処理するアプリをプログラムしたい場合はどうすればよいですか？

私の考えは私たちが今持っているものの反対でした。私はそれが完璧だと言っているわけではありませんが、今起こっていることよりも優れています。したがって、デフォルトでは、すべての非機密ファイルにアクセスできます。機密ファイルにアクセスする必要がある場合は、最初に質問する必要があります。

では、私が機密として選択しないのは正確には何でしょうか？すべてのアプリに休日の写真を表示させたくありませんが、Photoshopで表示できるはずです。それで、彼らは秘密ですか？または、この機密の「フラグ」はプログラムのリストであり、一部のファイルは一部のアプリの機密ではありませんか？

私の見方では、この「フラグ」はファイルまたはフォルダを「アクセス拒否」に変えます。本当にアクセスしたい場合は、許可を求めることができ、ユーザーはあなたに与えるかどうかを選択できます（そして、許可は、これだけ、または永久に）可能性があります。

ええ、私の言い回しはそこにゴミでした。申し訳ありません。私は、うまく機能する優れた「重要な」アプリが確実に存在することを示したかったのです。

ないというわけではありません。 WPFと比較して、作成するのはめちゃくちゃ難しいと言っています。
私は、単に存在してはならない問題に対処するために何日も無駄にしていると言っています。

たとえば、例外（具体的には、COM例外）が発生することがありますが、失敗した時点で取得するのではなく、実際には別のスレッドで取得します。ほとんどの場合、スタックトレースでさえ失った。何が起こったのかを理解することは非常に苦痛です。

もう1つの問題は、「情報を非同期にしよう」というマントラ全体です。これは私が非常に嫌いです。即時である必要があるレンダリングを扱っていますが、ビットマップのロードは非同期です。そのため、そのためだけに非常に複雑なキャッシュメカニズムを構築する必要がありました。

そして、コンパイル時間に入らないようにしましょう。そして最近、ビルドするときに、「... dllはリリースモードでビルドされます」というメッセージが表示されることがあります（デバッグをビルドしているため、基本的にはできません）。回避策は、すべてのソリューションをクリーンアップして再構築することです（1分以上かかります）。

そして、はい、クラッシュします。 VSは10〜20回の実行ごとにクラッシュしますが、その理由は私を打ち負かします。

そして、これらはちょうど今私の頭に浮かんだ問題です。数え切れないほどあります。

これはUWPの問題ではなく、次の事実に問題があります。
人々は通常コメントを書く傾向がありません
iTunesストア/ GooglePlayストアはMicrosoftストアよりもはるかに古いです
Microsoft Storeはユーザーの間で好評でなく、うまく開始されませんでした
プラットフォーム限定のアプリではなくウェブサイトの開発を好むほとんどの企業

ええと、私はAppleストアの比較ができたらよかったのにと思います-彼らのトップアプリには何百万ものレビューがあると確信しています。アイデアは、MSストアが決して追いつかないということです-人々は単にUWP / WinRTをあきらめるからです。 win2dが必要なかったら、少なくとも20回はあきらめていただろう。

考えてみてください。UWPアプリとして、Windowsに全画面表示にするように依頼する必要があります。それは正気を超えています。そしてそれをさらに愚かにするために、それは次の実行にのみ適用さ

「画面のスクリーンショットを取得する」APIを見ていました-私は単にそれをあきらめました、それは役に立たないです。私は基本的に、現在の画面に基づいてアプリを起動するクールな方法を望んでいました（一種の、私のアプリへの移行があります）->ユーザーの操作が必要なため、それは不可能です（つまり、ユーザーは言う必要があります-はい、スクリーンショットを取得できるようにしたいので、全体が台無しになります）

クリップボードから始めないでください。クリップボードは、アプリがフォアグラウンドにある場合にのみ機能します。さらに面白くするために、Microsoftは「デバッグ中はいつでもクリップボードにアクセスできるようにする」と考えていましたが、リリース時には、「アクセスが拒否されました」という優れた例外が発生します。私のアプリがリリースで起動しない理由を最終的に理解するのに何時間かかったか知っていますか（デバッグではすべてがダンディでしたが）

リストは続きます-私は本を書くことができたと思います。確かに、UWP / WinRTは理論的にはかっこいいです。しかし、あなたがそれから使い始めるとき、まあ..

ウェブサイトとアプリの見た目が大きく異なるため、電子であるかどうかを判断するのは困難です。ダイアログがデフォルトのダイアログとほぼ同じように見えるという事実に基づいて、それらはUWPアプリである可能性があります。

そうです、私のポイントは、人々はUWPアプリをあきらめるということです。その利点は、それに伴う多くの問題よりも重要です。

jtorjo 2020年01月26日

@jtorjo
（あなたがそれを知っていることを確認するためだけに。）

クリップボードから始めないでください。クリップボードは、アプリがフォアグラウンドにある場合にのみ機能します。

クリップボードにデータを配置する必要があるUWPアプリの開発中に同じ（または同様の）問題に到達し、最終的には付随するwin32完全信頼プロセス（Win32のSetClipboardDataを呼び出すだけ）を介して問題を解決しました。 UWPアプリにwin32の完全信頼プロセスを付随させるという概念がニュースである場合は、ここで適切な紹介を行い

Felix-Dev 2020年01月26日

@ Felix-Dev

クリップボードにデータを配置する必要があるUWPアプリの開発中に同じ（または同様の）問題に到達し、最終的には付随するwin32完全信頼プロセス（Win32のSetClipboardDataを呼び出すだけ）を介して問題を解決しました。 UWPアプリにwin32の完全信頼プロセスを付随させるという概念がニュースである場合は、ここで適切な紹介を行い

ポインタをありがとう！私はwin32の完全信頼プロセスについて知っていました。私はおそらくそれらの記事を数回読んだことがあります:)私は実際にwin32完全信頼プロセスコンパニオンアプリを数回持っていることを考えました。複雑さが増したため、そうしないことを選択しました。MSストアなしで実際に機能するセットアップキットを生成するのにすでに苦労しています。私はこれを方程式に取り入れたくありませんでした。

jtorjo 2020年01月26日

それで、フォルダ内のビデオファイルをプレビューするWindowsエクスプローラに似たものを構築していますか？

これは私のアプリのウィザードの一部です。

そのような音は、追加の手順を伴うファイルエクスプローラーのように聞こえます（⊙ˍ⊙）

私の考えは私たちが今持っているものの反対でした。私はそれが完璧だと言っているわけではありませんが、今起こっていることよりも優れています。したがって、デフォルトでは、すべての非機密ファイルにアクセスできます。機密ファイルにアクセスする必要がある場合は、最初に質問する必要があります。

したがって、基本的に、ファイルが機密であるかどうかがわからないため、最終的にはアプリで現在と同じ問題が発生する可能性があります。すべてを機密としてマークするユーザーはどうですか？つまり、アクセスできるバリエーションが増えただけで、今と同じシステムを作成したことになります。

たとえば、例外（具体的には、COM例外）が発生することがありますが、失敗した時点で取得するのではなく、実際には別のスレッドで取得します。ほとんどの場合、スタックトレースでさえ失った。何が起こったのかを理解することは非常に苦痛です。

それがあなたにとって頻繁に起こるなら、それは非常に迷惑です。ただし、私にとっては（XCGなどで）発生したほとんどすべての例外には、StackTraceが関連付けられており、場合によっては有用な例外メッセージもありました。ですから、それは私にとって本当に問題ではなかったので、私はそれについて何も言うことができません。

もう1つの問題は、「情報を非同期にしよう」というマントラ全体です。これは私が非常に嫌いです。即時である必要があるレンダリングを扱っていますが、ビットマップのロードは非同期です。そのため、そのためだけに非常に複雑なキャッシュメカニズムを構築する必要がありました。

非同期は少し面倒な場合がありますが、ネットワークやファイル操作などの操作でUIをブロックしたくないため、ほとんどの場合、非同期メソッドには非同期である理由があります。そうは言っても、次のメソッドを使用して非同期メソッドを同期的に実行できます。

`` `c＃
// MyAsyncMethodが終了するまでスレッドをブロックします
var myResult = MyAsyncMethod（）。Result;

//これもメソッドの実行が終了したときに終了します。
// ConfigureAwaitにより、メソッドが別のコンテキストで呼び出される可能性があることに注意してください
var myResult2 = MyAsyncMethod（）。ConfigureAwait（false）;
`` For ConfigureAwait`次の記事をご覧ください： //devblogs.microsoft.com/dotnet/configureawait-faq/

そして、コンパイル時間に入らないようにしましょう。そして最近、ビルドするときに、「... dllはリリースモードでビルドされます」というメッセージが表示されることがあります（デバッグをビルドしているため、基本的にはできません）。回避策は、すべてのソリューションをクリーンアップして再構築することです（1分以上かかります）。

「... dll」がリリースモードで構築されているのはおかしいです。プロジェクトファイルに一貫性がないかどうかを確認してください。コンパイル時間に関しては、はい、それは少し面倒ですが、〜1分はまだ大丈夫ですが、WinUIは約5〜10分かかります😅

そして、はい、クラッシュします。 VSは10〜20回の実行ごとにクラッシュしますが、その理由は私を打ち負かします。

ええ、それはかなり面倒ですが、これは実際にはUWPに依存しているとは思いませんが、一般的にはVisual Studioだけに依存しています（理由により、まだ32ビットプロセスです！）。

ええと、私はAppleストアの比較ができたらよかったのにと思います-彼らのトップアプリには何百万ものレビューがあると確信しています。アイデアは、MSストアが決して追いつかないということです-人々は単にUWP / WinRTをあきらめるからです。 win2dが必要なかったら、少なくとも20回はあきらめていただろう。

WPFでWin2Dを使用できるようです： https ：

考えてみてください。UWPアプリとして、Windowsに全画面表示にするように依頼する必要があります。それは正気を超えています。そしてそれをさらに愚かにするために、それは次の実行でのみ適用されます。

起動時でも、UWPアプリをフルスクリーンモードにすることは可能のようです： https ：
（私はそれでアプリを提出しようとはしていませんが）

「画面のスクリーンショットを取得する」APIを見ていました-私は単にそれをあきらめました、それは役に立たないです。私は基本的に、現在の画面に基づいてアプリを起動するクールな方法を望んでいました（一種の、私のアプリへの移行があります）->ユーザーの操作が必要なため、それは不可能です（つまり、ユーザーは言う必要があります-はい、スクリーンショットを取得できるようにしたいので、全体が台無しになります）

ほとんどのユーザーは、アプリが許可なく画面の写真を勝手に撮ることを望んでいません。あなたはそれで問題がないかもしれません、しかし私は確かにそうします、そして他の多くもそうします。

クリップボードから始めないでください。クリップボードは、アプリがフォアグラウンドにある場合にのみ機能します。さらに面白くするために、Microsoftは「デバッグ中はいつでもクリップボードにアクセスできるようにする」と考えていましたが、リリース時には、「アクセスが拒否されました」という優れた例外が発生します。私のアプリがリリースで起動しない理由を最終的に理解するのに何時間かかったか知っていますか（デバッグではすべてがダンディでしたが）

はい、例外が発生しますが、フォーカスがない場合にアプリがアクセスできないという事実は、ドキュメントに記載されています。

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

しかし、ユーザーがアプリを使用していないのに、なぜクリップボードにアクセスする必要があるのでしょうか。ユーザーがアプリを使用していないときにクリップボードを設定しようとすると、コピー/貼り付けを妨害するとユーザーはイライラします。そして、ユーザーがアプリにそれを要求していないときにクリップボードを読んだ場合、あなたは彼をスパイしていることになります。それが目標でない限り（その場合は絶対にUWPを使用しないでください）、アプリにフォーカスがないときにクリップボードを読み取る理由はほとんどありません（ある場合）。

そうです、私のポイントは、人々はUWPアプリをあきらめるということです。その利点は、それに伴う多くの問題よりも重要です。

たぶん、しかしまた、すべてのプラットフォーム用に別々のアプリを作成する代わりに、Webサイトを作成してElectron内にパックし、Mac、Linux、およびWindowsに出荷する方が簡単であるという事実によってもです。

chingucoding 2020年01月26日

そのような音は、追加の手順を伴うファイルエクスプローラーのように聞こえます（⊙ˍ⊙）

そうではありません。それからは程遠い。

したがって、基本的に、ファイルが機密であるかどうかがわからないため、最終的にはアプリで現在と同じ問題が発生する可能性があります。すべてを機密としてマークするユーザーはどうですか？つまり、アクセスできるバリエーションが増えただけで、今と同じシステムを作成したことになります。

私の解決策が正しいと言っているのではありません。明らかに、私はサンドボックスに入れたくないのですが、現在の実装は非常に悪いと言っているだけです。

非同期は少し面倒な場合がありますが、ネットワークやファイル操作などの操作でUIをブロックしたくないため、ほとんどの場合、非同期メソッドには非同期である理由があります。そうは言っても、次のメソッドを使用して非同期メソッドを同期的に実行できます。

これは間違っています。これは、私が常にUIスレッドから呼び出すことを前提としています。これは単純なものには問題ないことを意味しますが、独自のスレッドを作成したり、独自のタスクを作成してそこで作業を行ったりすることもできます。

すべてを非同期にすると、常にawaitを呼び出し、関数を非同期としてマークする必要があります。

[...] ConfigureAwaitについては、次の記事をご覧ください： //devblogs.microsoft.com/dotnet/configureawait-faq/

おかげで、私はこれについて知っています。私が遭遇した別の問題は、あなたが提案したとおりにビットマップ（非同期）をロードすることでした。時々、ビットマップをロードするのに5〜6秒のような非常識な待機時間に遭遇しました。
結局、回避策を実行しました。

「... dll」がリリースモードで構築されているのはおかしいです。プロジェクトファイルに一貫性がないかどうかを確認してください。コンパイル時間に関しては、はい、それは少し面倒ですが、〜1分はまだ大丈夫ですが、WinUIは約5〜10分かかります😅

ええ、私はそれについて考えたくありません:)プロジェクトファイルが一貫していないことについてあなたが何を意味するのかわかりません。

そして、はい、クラッシュします。 VSは10〜20回の実行ごとにクラッシュしますが、その理由は私を打ち負かします。
ええ、それはかなり面倒ですが、これは実際にはUWPに依存しているとは思いませんが、一般的にはVisual Studioだけに依存しています（理由により、まだ32ビットプロセスです！）。

UWPに関連していると思います。 WPFを扱っているとき、これは私には決して起こりませんでした-私には28のプロジェクトがあり、クラッシュすることはありませんでした。 UWPには15個のプロジェクト（WPFから移植したもの）があり、クラッシュします。また、イベントビューアを見ると、サンドボックスのクラッシュについて何かがあります。正確には覚えていません。

WPFでWin2Dを使用できるようです： microsoft / Win2D＃660

それが私の最初の試みでした。それは完全にノーゴーです。私は非常に多くの問題に遭遇したので、あきらめました。 win2dを処理するコードは非常に複雑なので、UWPを直接使用するよりも、WPFの上に記述する方がはるかに時間がかかると考えました。

UWPのセットアップがそのまま嫌いなのと同じくらい、私は正しかった。私はそれを適切に機能させることができなかっただろう。そして、私はあなたがhttps://github.com/microsoft/Win2D/issues/731を知っていると思います

考えてみてください。UWPアプリとして、Windowsに全画面表示にするように依頼する必要があります。それは正気を超えています。そしてそれをさらに愚かにするために、それは次の実行でのみ適用されます。
起動時でも、UWPアプリをフルスクリーンモードにすることは可能のようです： https ：

申し訳ありませんが、私は「最大化する」という意味でした-申し訳ありません。

はい、例外が発生しますが、フォーカスがない場合にアプリがアクセスできないという事実は、ドキュメントに記載されています。

問題は、デバッグとリリースでの動作が異なることです。一貫している必要があります。

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard
しかし、ユーザーがアプリを使用していないのに、なぜクリップボードにアクセスする必要があるのでしょうか。 [...]

面白いのはこれです-起動時にクリップボードに何かをコピーしたかったのです。ただし、これはMainPageのコンストラクターにあるため、明らかに、私はまだフォアグラウンドにいませんでした。デバッグで桃色に動作し、リリースでクラッシュしました。つまり、起動時に正確にログを記録せず、何も記録しません。

そうです、私のポイントは、人々はUWPアプリをあきらめるということです。その利点は、それに伴う多くの問題よりも重要です。
たぶん、しかしまた、すべてのプラットフォーム用に別々のアプリを作成する代わりに、Webサイトを作成してElectron内にパックし、Mac、Linux、およびWindowsに出荷する方が簡単であるという事実によってもです。

プラットフォームの独立性に関して言えば、これはまったく新しいトピックです。私が言及したのは、UWPアプリの開発時に人々が遭遇する多くの問題が単に存在してはならないという事実です。 WPFからUWPへの切り替えは、非常に悪い経験でした。

jtorjo 2020年01月26日

@chingucoding

しかし、ユーザーがアプリを使用していないのに、なぜクリップボードにアクセスする必要があるのでしょうか。ユーザーがアプリを使用していないときにクリップボードを設定しようとすると、コピー/貼り付けを妨害するとユーザーはイライラします。そして、ユーザーがアプリにそれを要求していないときにクリップボードを読んだ場合、あなたは彼をスパイしていることになります。それが目標でない限り（その場合は絶対にUWPを使用しないでください）、アプリにフォーカスがないときにクリップボードを読み取る理由はほとんどありません（ある場合）。

私の場合、アプリが監視しているイベントが発生すると、アプリに通知が表示されることがあります。トースト通知には、ユーザーがさらに処理したい/別のコンテキストで使用したい情報が含まれている可能性があるため、表示された情報の一部をコピーする[クリップボードにコピー]アクションボタンを提供します。通知はいつでも届く可能性があり、その時点でアプリがバックグラウンドにある可能性が非常に高いため、その場合はWin32ヘルパープロセスを使用する必要があります。

UWPサンドボックスの外部でWin32を使用するのは、開発者がユーザーに知らないうちに何かを達成したいからというわけではありません。したがって、一般的に言って、サンドボックスはユーザーに価値を提供しますが、ユーザーをスパイすることを気にしない、または要求する意図がない悪意のある開発者でなくても、どのような場合でも開発者として扱う必要がありますシステム上の何かを変更する前のユーザーの同意。

アプリと一緒にWin32完全信頼プロセスを使用できるという事実は、MSがこのジレンマを認識しており、開発者にUWPを使用するためのツールを提供し、Win32の自由を十分に享受できることを示しています。

Felix-Dev 2020年01月26日

👍1

そうではありません。それからは程遠い。

今すぐアプリをダウンロードできますか？もしそうなら、どこでそれを見つけることができますか？ 😅

明らかに、私はサンドボックスに入れたくないのですが、現在の実装は非常に悪いと言っているだけです。

サンドボックスが気に入らない場合は、明らかにしたUWPでアプリを開発するのではなく、WPFの代替手段に切り替える方が良い選択かもしれませんが、「不可能」または「めちゃくちゃ難しい」と思います。のアプリを開発します。 WPFの代替案がWin2Dに比べてそれほど悪いとは思わないので、すべての苦労を経験することを正当化するでしょう。しかし、それは私の見解です。

また、現在の実装は、ファイルに関する制限がないことに慣れている人々にとっては「悪い」ものです。 Web開発のバックグラウンドから来て、私はそれで非常に元気です。特にWebにはユーザーを保護することを目的とした制限があるため、私は彼らの場所を見ることができます。

プロジェクトファイルが一貫していないとはどういう意味かわかりません。

デバッグ用のプロジェクトファイルが間違っていて、リリース時にいくつかのdllが生成されている可能性がありますが、VisualStudioに処理させるだけでは発生しないと思います。

UWPに関連していると思います。 WPFを扱っているとき、これは私には決して起こりませんでした-私には28のプロジェクトがあり、クラッシュすることはありませんでした。 UWPには15個のプロジェクト（WPFから移植したもの）があり、クラッシュします。また、イベントビューアを見ると、サンドボックスのクラッシュについて何かがあります。正確には覚えていません。

Visual Studioの信頼性は、私にとってプロジェクトのサイズに大きく依存します。小/中UWP / NetCore / NetFrameworkは常に正常に機能します。大規模なプロジェクトでは、Visual Studioが応答しなくなったり、ハングしたり、単にクラッシュしたりします。しかし、それは私の経験です。

申し訳ありませんが、私は「最大化する」という意味でした-申し訳ありません。

その場合、アプリの起動後に値を設定するため、変更は次回の起動時にのみ適用されます。「Windowsに聞いてみないと」ってどういう意味かわかりません。コードで設定する必要があるという事実に言及していますか？

また、希望のサイズを設定する方法もあります。これにより、アプリは実際の最大化ほど良くはありませんが、画面上のすべてのスペースを占有することになります（最大化と同様）。
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

これは間違っています。これは、私が常にUIスレッドから呼び出すことを前提としています。これは単純なものには問題ないことを意味しますが、独自のスレッドを作成したり、独自のタスクを作成してそこで作業を行ったりすることもできます。

すでに独自のスレッドを使用している場合は、awaitを使用しても問題はありません。別々のスレッドを使用している場合でも、イベントハンドラーは常にUIスレッドで実行されるため、そこで大規模な計算を行うと、アプリが応答しなくなります。

UWPのセットアップがそのまま嫌いなのと同じくらい、私は正しかった。私はそれを適切に機能させることができなかっただろう。そして、私はあなたがmicrosoft / Win2D＃731を知っていると思います

気づかなかったのですが、2018年からお話しした問題なので、今では問題なく解決できると思いました。

問題は、デバッグとリリースでの動作が異なることです。一貫している必要があります。

うーん、それはとても奇妙です。動作は一貫している必要があります。

面白いのはこれです-起動時にクリップボードに何かをコピーしたかったのです。

また、ドキュメントでそのユースケースについて言及しているため、CoreWindow.Activatedがコピーされるのを待つ必要があります。ユーザーがアプリを起動したばかりのときに、なぜクリップボードに何かを正確にコピーするのでしょうか。 @ Felix-Devが達成したい/達成したいものに似た何か？

@ Felix-Dev返信ありがとうございます。私はそのシナリオについては考えていませんでした。その場合、はい、クリップボードにアクセスする必要があります。これにより、ユーザーのエクスペリエンスが確実に向上します。私の推測では、あなたが乾杯したので「焦点が合っている」ので、これはうまくいったでしょう。しかし、そうではないと思います。

したがって、一般的に言って、サンドボックスはユーザーに価値を提供しますが、ユーザーをスパイすることを気にしない、または要求する意図がない悪意のある開発者でなくても、どのような場合でも開発者として扱う必要がありますシステム上の何かを変更する前のユーザーの同意。

はい、対処する必要がありますが、多くのアプリはサンドボックスによって制限されていないため、回避策を見つけるのは非常に困難です。また、UWPが機能しない場合でも、他に2つのオプションがあることを忘れないでください。

最後のポイントに関しては、はい、Win32プロセスを使用できるという事実は、UWPが制限している場合があることを示しています。
多分これは手元で最も簡単/最速の回避策でした、あるいは多分それは実際には設計によるものです。

chingucoding 2020年01月26日

そうではありません。それからは程遠い。
今すぐアプリをダウンロードできますか？もしそうなら、どこでそれを見つけることができますか？ 😅

ここ-> https://phot-awe.com

サンドボックスが気に入らない場合は、明らかにしたUWPでアプリを開発するのではなく、WPFの代替手段に切り替える方が良い選択かもしれませんが、「不可能」または「めちゃくちゃ難しい」と思います。のアプリを開発します。 WPFの代替案がWin2Dに比べてそれほど悪いとは思わないので、すべての苦労を経験することを正当化するでしょう。しかし、それは私の見解です。

これはWPFアプリケーションでした。ただし、ビデオ編集の性質上、速度の点でWPFの限界に長い間到達していました（基本的に、 DrawingVisual ）。私を信じてください、もし私に選択があったなら、私はこれをしなかっただろう。

また、現在の実装は、ファイルに関する制限がないことに慣れている人々にとっては「悪い」ものです。 Web開発のバックグラウンドから来て、私はそれで非常に元気です。特にWebにはユーザーを保護することを目的とした制限があるため、私は彼らの場所を見ることができます。

私はあなたがウェブのバックグラウンドから来ていると誓ったかもしれません:)

デバッグ用のプロジェクトファイルが間違っていて、リリース時にいくつかのdllが生成されている可能性がありますが、VisualStudioに処理させるだけでは発生しないと思います。

そうではありませんが、私は再確認しました-そうではありません。

Visual Studioの信頼性は、私にとってプロジェクトのサイズに大きく依存します。小/中UWP / NetCore / NetFrameworkは常に正常に機能します。大規模なプロジェクトでは、Visual Studioが応答しなくなったり、ハングしたり、単にクラッシュしたりします。しかし、それは私の経験です。

はい、私は過去にそれを扱ったことがあります。最新バージョンのVS（2017,2019）には当てはまらないようです。とにかく、簡単に言えば、これは私にとってUWPで起こっただけです。それは私がwin2dを使用しているという事実と関係があるかもしれません、そして私はかなり複雑な獣であると感じています。

その場合、アプリの起動後に値を設定するため、変更は次回の起動時にのみ適用されます。「Windowsに聞いてみないと」ってどういう意味かわかりません。コードで設定する必要があるという事実に言及していますか？

WPFでは、ウィンドウサイズを希望の場所に設定するだけです。ここに、呼び出す必要のあるAPIがあります-> ApplicationView.PreferredLaunchViewSize -ドキュメントにあるように、「システムがウィンドウサイズを直接管理する場合を除いて、機能します」。 -そして、ええ、それは次のアプリの起動時にのみ機能します。

また、希望のサイズを設定する方法もあります。これにより、アプリは実際の最大化ほど良くはありませんが、画面上のすべてのスペースを占有することになります（最大化と同様）。
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

私は実際に正しく機能する別のコードを使用しています

var view = DisplayInformation.GetForCurrentView();
var resolution = new Size(view.ScreenWidthInRawPixels, view.ScreenHeightInRawPixels);
var scale = view.ResolutionScale == ResolutionScale.Invalid ? 1 : view.RawPixelsPerViewPixel;
var bounds = new Size(resolution.Width / scale, resolution.Height / scale);

ApplicationView.PreferredLaunchViewSize = new Size(bounds.Width, bounds.Height);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;

すでに独自のスレッドを使用している場合は、awaitを使用しても問題はありません。別々のスレッドを使用している場合でも、イベントハンドラーは常にUIスレッドで実行されるため、そこで大規模な計算を行うと、アプリが応答しなくなります。

明らかに、イベントハンドラーはUIスレッドで実行されます。私はそれに慣れてきました、私は私のアプリのかなりの部分を変更する必要がありました-関数に非同期を追加するだけです...それでも本当に私を悩ませているのは、かなりの数のAPIがこれを取っているように見えることです極端な場合、Async（）のみのバージョンがあり、意味がありません。

気づかなかったのですが、2018年からお話しした問題なので、今では問題なく解決できると思いました。

少なくとも前回チェックしたときはそうではありませんでした。

問題は、デバッグとリリースでの動作が異なることです。一貫している必要があります。
うーん、それはとても奇妙です。動作は一貫している必要があります。

ええ、それは本当に私を怒らせたものです。そして明らかに、UWP以外のアプリでクリップボードを非常に長い間使用していたので、これらの制限があるとは思わなかったので、CoreWindow.Activatedを待つ必要があることについては読んでいませんでした。そうは言っても、これらすべての詳細を学ばなければならないのは非常に面倒です。まったく新しい言語を学ぶ必要があるようなものです。シームレスなプロセスではなく、毎週、心を打たれるようなことを学んでいるようです。

また、ドキュメントでそのユースケースについて言及しているため、CoreWindow.Activatedがコピーされるのを待つ必要があります。ユーザーがアプリを起動したばかりのときに、なぜクリップボードに何かを正確にコピーするのでしょうか。 @ Felix-Devが達成したい/達成したいものに似た何か？

これは、私がアプリを初期にテストしていたときであり、さらに内部テストを行うために同僚に提供したかっただけです。ただし、彼はいくつかの設定を微調整する必要があります。そして、設定はアプリケーションのLocalFolderに保持されました。これはユーザーごとに異なるので、私の考えは-これを単純にしてクリップボードにコピーさせてください。次に、アプリを起動すると、[このPC]に移動し、場所を貼り付けて、そこで設定ファイルを編集します（これで、エクスプローラーでアプリを開く方法がわかりましたが、そのときはしませんでした）。それは結局クラッシュしました、そして私は数時間の間調査して呪いをかけました。

jtorjo 2020年01月26日

ここ-> https://phot-awe.com

ありがとう！

これはWPFアプリケーションでした。ただし、ビデオ編集の性質上、速度の点でWPFの限界に長い間到達していました（基本的に、DrawingVisualの処理）。私を信じてください、もし私に選択があったなら、私はこれをしなかっただろう。

WPFがUWPに比べてパフォーマンスが大幅に低下していることを知りませんでした。

そうではありませんが、私は再確認しました-そうではありません。

それは変だ。私は何かがおかしいと思っていたでしょう。デバッグを実行しているときに、VSがリリースdllについて話すのはなぜですか。

WPFでは、ウィンドウサイズを希望の場所に設定するだけです。ここに、呼び出す必要のあるAPI（ApplicationView.PreferredLaunchViewSize）があります。これは、ドキュメントに記載されているように、「システムがウィンドウサイズを直接管理する場合を除いて、機能します」。

しかし、使用しているコードは、ウィンドウサイズを設定するためのAPIでもありませんか？

そして、ええ、それは次のアプリの起動時にのみ機能します。

「PreferredLaunchViewSize」と呼ばれるのは当然のことです😅
起動後にこれを設定する方法がないのは少し不便です。

はい、私は過去にそれを扱ったことがあります。最新バージョンのVS（2017,2019）には当てはまらないようです。とにかく、簡単に言えば、これは私にとってUWPで起こっただけです。

以前のバージョンのVSほど悪くはないと聞いてうれしいです。

それは私がwin2dを使用しているという事実と関係があるかもしれません、そして私はかなり複雑な獣であると感じています。

テンプレートバインディングで失敗し始めるので、私はデザイナーにあまり依存しません。 Blend for Visual Studioを試しましたか？それはデザイナーに関してより信頼できますか？

ええ、それは本当に私を怒らせたものです。そして明らかに、UWP以外のアプリでクリップボードを非常に長い間使用していたので、これらの制限があるとは思わなかったので、CoreWindow.Activatedを待つ必要があることについては読んでいませんでした。そうは言っても、これらすべての詳細を学ばなければならないのは非常に面倒です。まったく新しい言語を学ぶ必要があるようなものです。シームレスなプロセスではなく、毎週、心を打たれるようなことを学んでいるようです。

はい、私はそれを想像することができます。良いかもしれない何かは、WPFからUWPへの移行ガイドです。これが存在する場合、それは間違いなく新しいUWPと以前のWPF開発者に多くの時間を節約するでしょう。そして、移行ガイドがあるのはこれが初めてではありません。 JavaからC＃へのガイドがすでにあります。これはJava開発者に大いに役立ちます。

これは、私がアプリを初期にテストしていたときであり、さらに内部テストを行うために同僚に提供したかっただけです。ただし、彼はいくつかの設定を微調整する必要があります。そして、設定はアプリケーションのLocalFolderに保持されました。これはユーザーごとに異なるので、私の考えは-これを単純にしてクリップボードにコピーさせてください。次に、アプリを起動すると、[このPC]に移動し、場所を貼り付けて、そこで設定ファイルを編集します（これで、エクスプローラーでアプリを開く方法がわかりましたが、そのときはしませんでした）。それは結局クラッシュしました、そして私は数時間の間調査して呪いをかけました。

ああなるほど。フォルダを開くことを考えていない場合は、フォルダパスをクリップボードにコピーするのが解決策です。テストの目的では、これは非常に賢明です。

chingucoding 2020年01月26日

WPFがUWPに比べてパフォーマンスが大幅に低下していることを知りませんでした。

WPFはDirectX用に最適化されていませんでした-ピクセルシェーダーとマスクが機能するようになると、非常に遅くなります。 UWP / win2dに移植すると、アプリが3〜4倍高速になりました。それはめちゃくちゃ目立ちます。

それは変だ。私は何かがおかしいと思っていたでしょう。デバッグを実行しているときに、VSがリリースdllについて話すのはなぜですか。

ええ、まさに私のポイントです。

しかし、使用しているコードは、ウィンドウサイズを設定するためのAPIでもありませんか？

つまり、Preferred ... Sizeを使用しますが、それが発生する保証はありません。 WPFを使用する場合と同様に、位置/サイズを設定すると、実際に発生することが保証されます。

「PreferredLaunchViewSize」と呼ばれるのは当然のことです😅
起動後にこれを設定する方法がないのは少し不便です。

これは不便を超えています-それはめちゃくちゃ不便です。基本的に、一度起動するとアプリのサイズを変更できません。はい、アプリにさまざまな「モード」の操作（基本/詳細など）を持たせたいのですが、それに基づいて、多かれ少なかれスペースを取りたいと思いますが、それはできません。「変更は再起動後にのみ発生します」でユーザーは大丈夫だと思いますか？

テンプレートバインディングで失敗し始めるので、私はデザイナーにあまり依存しません。 Blend for Visual Studioを試しましたか？それはデザイナーに関してより信頼できますか？

もっと具体的にすべきだった-xamlの編集時にVSがクラッシュしない-アプリの起動時にクラッシュする。基本的に、（uwp）アプリに大きな「x」が10秒間表示されるだけなので、展開時に正確に発生すると思います。その時点で、ハングしていることがわかります。その時点で、さらに45〜60秒待って、VSがクラッシュすることを確認するか、タスクマネージャーからVSを閉じることができます。

はい、私はそれを想像することができます。良いかもしれない何かは、WPFからUWPへの移行ガイドです。

はい、それは非常に役立ちます。

ああなるほど。フォルダを開くことを考えていない場合は、フォルダパスをクリップボードにコピーするのが解決策です。テストの目的では、これは非常に賢明です。

ありがとう;）それが実際に機能していたら、それは賢かったでしょう:)

jtorjo 2020年01月27日

@chingucoding

非同期は少し面倒な場合がありますが、ネットワークやファイル操作などの操作でUIをブロックしたくないため、ほとんどの場合、非同期メソッドには非同期である理由があります。そうは言っても、次のメソッドを使用して非同期メソッドを同期的に実行できます

私が非同期を嫌うもう1つの理由を挙げましょう-これはちょうど今私に起こりました（基本的に、それはユーザーからのバグレポートです）。当初、私は自分の人生のためにそれを理解することができませんでした。

簡単に言うと、ボタンをクリックすると、ファイルピッカーが開きます。ご想像のとおり、これは非同期です。

したがって、ユーザーはそれをダブルクリックしました（クリックの間に約100ミリ秒の一時停止があります）。確かに、これは2つのファイルピッカーを開きました。

これで、明らかにこれを修正できますが、最初の関数が同期していれば、これは発生しません（もちろん、これはWPFでは発生しません）。

jtorjo 2020年01月28日

これは不便を超えています-それはめちゃくちゃ不便です。基本的に、一度起動するとアプリのサイズを変更できません。はい、アプリにさまざまな「モード」の操作（基本/詳細など）を持たせたいのですが、それに基づいて、多かれ少なかれスペースを取りたいと思いますが、それはできません。「変更は再起動後にのみ発生します」でユーザーは大丈夫だと思いますか？

「めちゃくちゃ不便」なのは、特定のサイズを適用する必要があるアプリの場合ですが、ほとんどの場合、アプリは自分でサイズを変更する必要はありません。アプリは、ユーザーのユースケースに現在適切なサイズをどのように選択する必要がありますか？ユーザーがそれを小さくしたり大きくしたりする必要がある場合、ユーザーが最初にそれに気付くよりも。特に彼は、他の開いているウィンドウがどこにあるか、他のウィンドウが表示されないようにブロックしないようにスペースを利用できる場所を最もよく知っているためです。

基本モードと詳細モードを使用している場合、小さいときにアプリが確実に機能しない場合は、最小推奨サイズを変更できます。しかし、私の意見では、プログラムが自分自身のサイズを変更し始めるとしたら、それは私にとって非常に苛立たしいことです（そして幸いなことに、これを行うプログラムは今のところありません）。

できません。「変更は再起動後にのみ発生します」でユーザーは大丈夫だと思いますか？

サイズ変更が非常に重要な場合は、ユーザーが自分で行うことができます。ただし、この「変更は再起動後にのみ発生する」というのは珍しいことではないので、私の意見では部分的に受け入れられます。

したがって、ユーザーはそれをダブルクリックしました（クリックの間に約100ミリ秒の一時停止があります）。確かに、これは2つのファイルピッカーを開きました。

なぜファイルピッカーを2回正確に開いたのですか？イベントハンドラーは2回トリガーされましたか？これは非同期が原因の問題ではなく、イベントハンドラーがUIがそれぞれのボタンから追加のイベントを受信するのをブロックしなかったという事実によるものです。

簡単に言うと、ボタンをクリックすると、ファイルピッカーが開きます。ご想像のとおり、これは非同期です。

はい、ユーザーがドライブをナビゲートしてフォルダーを選択している間はスレッド全体をブロックしたくないため、非同期です。ユーザーがファイル/フォルダーの選択を終了すると呼び出しが終了し、その結果、選択したファイルが取得されます。

私の意見では、実際にかかる時間がわからないため、このような操作でスレッドをブロックしない方がよいと思います。そのためにUIスレッドをブロックすると、ファイルピッカーが開いている限りアプリが応答しなくなります。IMOは優れたUXではありません。

chingucoding 2020年02月03日

敬意を表してこれを言うことから始めましょう：

明らかにあなたはウェブの観点から考えていて、単に「デスクトップ」として何も見ていません。いい意味だとは思いますが、デスクトップに関しては、複雑なものを開発するまで「デスクトップ」を考えているだけではありません。そして、私はあなたがそうしていないと信じています。

「めちゃくちゃ不便」なのは、特定のサイズを適用する必要があるアプリの場合ですが、ほとんどの場合、アプリは自分でサイズを変更する必要はありません。アプリは、ユーザーのユースケースに現在適切なサイズをどのように選択する必要がありますか？ユーザーがそれをユーザーよりも小さくしたり大きくしたりする必要がある場合

あなたは真剣にこれを求めていますか？アプリケーションはユーザーを助けることになっているのではありませんか？そして、ユーザーがアプリのサイズに問題がある場合は、サイズを変更できます。しかし、アプリは、それが達成することになっていることに基づいて、これが私が実行すべきサイズであると言うことができるはずです。たとえば、Photoshopは、ユーザーに表示する情報がたくさんあるため、常にフルスクリーンで実行することを好みます。

基本モードと詳細モードを使用している場合、小さいときにアプリが確実に機能しない場合は、最小推奨サイズを変更できます。しかし、私の意見では、プログラムが自分自身のサイズを変更し始めるとしたら、それは私にとって非常に苛立たしいことです（そして幸いなことに、これを行うプログラムは今のところありません）。

もしそうなら、あなたはそれについて考えさえしませんでした。ウィザードは小さいサイズで実行されることがあり、ウィザードが終了すると、アプリが全画面表示になる場合があります。

できません。「変更は再起動後にのみ発生します」でユーザーは大丈夫だと思いますか？
サイズ変更が非常に重要な場合は、ユーザーが自分で行うことができます。ただし、この「変更は再起動後にのみ発生する」というのは珍しいことではないので、私の意見では部分的に受け入れられます。

また、特定のサイズでしか見栄えのしないウィンドウを表示するため、起動時のエクスペリエンスが悪くなります。Windowsには「ああ、でもアプリは好きなように表示します」とだけ表示されます。

なぜファイルピッカーを2回正確に開いたのですか？イベントハンドラーは2回トリガーされましたか？これは非同期が原因の問題ではなく、イベントハンドラーがUIがそれぞれのボタンから追加のイベントを受信するのをブロックしなかったという事実によるものです。

あなたは正直にこれをしていますか？これを意識的に行った場所でコードがどのように切り取られたかを見せてください。

私の意見では、実際にかかる時間がわからないため、このような操作でスレッドをブロックしない方がよいと思います。そのためにUIスレッドをブロックすると、ファイルピッカーが開いている限りアプリが応答しなくなります。IMOは優れたUXではありません。

WPFはこれをどのように処理しますか？それは正しく処理します。 UIはブロックしませんが、アプリはその呼び出しでブロックします-したがって、上記はWPFでは発生しません

jtorjo 2020年02月03日

👍2

敬意を表してこれを言うことから始めましょう：私たちは何にも同意しません。

これがこの議論に対するあなたの見解であるならば、それについて申し訳ありません。

明らかにあなたはウェブの観点から考えていて、単に「デスクトップ」として何も見ていません。いい意味だとは思いますが、デスクトップに関しては、複雑なものを開発するまで「デスクトップ」を考えているだけではありません。そして、私はあなたがそうしていないと信じています。

より正確な説明は次のようになると思います。私は開発者が何にもアクセスできないバックグラウンドから来ており、開発者がすべてのOSリソースにアクセスできるバックグラウンドから来ています。

もしそうなら、あなたはそれについて考えさえしませんでした。ウィザードは小さいサイズで実行されることがあり、ウィザードが終了すると、アプリが全画面表示になる場合があります。

はい、ウィザードは小さいサイズで実行されますが、ほとんどのウィザード（Visual Studio 2019スタートアップ「ウィザード」を含む）は自動的に閉じてから、実際のプログラムを開始します。それらは実際のアプリケーションに「変形」しません。

一部のウィザードも新しいウィンドウではなく、実際のアプリケーションがバックグラウンドにある単なるポップアップであることに注意してください。

また、特定のサイズでしか見栄えのしないウィンドウを表示するため、起動時のエクスペリエンスが悪くなります。Windowsには「ああ、でもアプリは好きなように表示します」とだけ表示されます。

Windowsが常にコードを無視しているように見せますが、いつ無視するかは明らかです（「PreferredLaunchViewSize」のドキュメントから取得）。

このプロパティは、タブレットモードではないデスクトップデバイスでアプリを起動した場合にのみ効果があります。

そのため、タブレット以外のモードのデスクトップでのみ機能します。しかし、実際にサイズを要求することは他のデバイスでは意味がありますか？アプリがX-BoxまたはHoloLensで実行されることを期待し、そのようなデバイス用に最適化しましたか？そうでない場合は、この制限がそれほど気になることはないはずです。

あなたは正直にこれをしていますか？これを意識的に行った場所でコードがどのように切り取られたかを見せてください。

いいえ、私はそうではありません。私は、あなたがそれに関係のない何かの「非同期」を非難しているという事実を指摘しようとしていました。ユーザーがボタンを2回クリックすると、クリックされたイベントが2回トリガーされます。

WPFはこれをどのように処理しますか？それは正しく処理します。 UIはブロックしませんが、アプリはその呼び出しでブロックします-したがって、上記はWPFでは発生しません

UIスレッドでコードを実行し、WPFでUIスレッドをブロックするよりも、完了するまでに時間がかかるかどうかはかなり確信しています。

chingucoding 2020年02月03日

👍2

こんにちは、私はWindowsOSチームのWindowsSDKおよびWindowsランタイムインフラストラクチャの開発リーダーです。

これは、多くの詳細と会話を伴う素晴らしい議論です。数日前に誰かがこの会話を持ってきて、それを読むのを楽しみにしていますが、それでも私がそれに到達するまでに数日かかるかもしれません。ただし、すべてを読み、より詳細な回答を提供するか、できる限りフォローアップするように努めます。

これはおそらく、winrtの一般的な問題に最適な場所ではありません。 Microsoft開発者フォーラムで問題を提起するか、特にWindowsランタイムの問題については、 https：//github.com/microsoft/xlangで問題を開くことができ

活発な議論をありがとうございました。この問題については、すぐにまた投稿します。

ベン・クーン
マイクロソフト

BenJKuhn 2020年03月26日

👍3 ❤1

ベンさん、こんにちは、

こんにちは、私はWindowsOSチームのWindowsSDKおよびWindowsランタイムインフラストラクチャの開発リーダーです。
これは、多くの詳細と会話を伴う素晴らしい議論です。数日前に誰かがこの会話を持ってきて、それを読むのを楽しみにしていますが、それでも私がそれに到達するまでに数日かかるかもしれません。ただし、すべてを読み、より詳細な回答を提供するか、できる限りフォローアップするように努めます。

素晴らしい-あなたの返事を楽しみにしています！

私はオリジナルのポスターですので、ご不明な点やご不明な点がございましたら、お気軽にお問い合わせください。できる限り明確にさせていただきます。

これはおそらく、winrtの一般的な問題に最適な場所ではありません。 Microsoft開発者フォーラムで問題を提起するか、特にWindowsランタイムの問題については、 https：//github.com/microsoft/xlangで問題を開くことができ

最高の場所ではないことに同意しました。問題は、人々がどこに投稿すればよいかわからないことです。

https://github.com/microsoft/xlangに投稿する必要があるとおっしゃる場合は、今後必ず投稿します。

一番、
ジョン

jtorjo 2020年03月26日

最初に、私が取り上げないいくつかのことを指摘させてください。

•スレッドの下部近くで、ウィンドウ処理、ウィンドウ位置などについて多くのすばらしい議論があります。それはおそらくWinUIにとっては少し外れたトピックですが、より身近なものです。 WinUIの人々に、ウィンドウの位置や全画面などに関するフィードバックを解析させ、リダイレクトを支援したいと思います。 @StephenLPeters 、これを手伝ってくれませんか？

•VSフィードバックには触れません。 VSの品質とパフォーマンスについて議論するための健全なフォーラムがあります。 Visual StudioからWindowsアプリを開発するための話がもう少し複雑になり、混乱しているという議論に注意しましたが。

•WPF。私はWPFと愛憎関係にあります。それは便利で、ほとんどが良いです。ファイルピッカーのネストされたクリックに関するコメントを読んだとき、それは私を笑わせました。 WPFにはいくつかの癖があり、それが私に本当の頭痛の種を与えているからです。 WPFでドラッグすると、ドラッグメッセージがネストされたメッセージで二重にディスパッチされることがあるため、実際にはモーダルドラッグ内でモーダルドラッグを実行しています。通常、気付くことはありません。いつもの。しかし、私はまだWPFが好きです。 😉

第二に、 @ verelpode ：これは私を笑わせました。私がこれに固執してもいいですか？
「私はあなたが直接の真実を扱うことができないと信じているので、私はあなたを厚いふわふわの綿の手袋で扱い、プチプチであなたを詰めます」

では、実際のトピックに移りましょう。

WinRT vs. UWP vs. .NET –いくつかの背景

Windowsランタイムは、実際には2つのものが1つにまとめられ、別のものに詰め込まれ、実際に誤解されています。

Windowsランタイム型システムは、ある意味でCOMV2です。これは、割り込みのトリガーからWin32の呼び出し、COMAPIの呼び出しまでの進行における精神的な次のステップです。型システムは、COMでは表現力がやや劣りますが、ほとんどの場合、実質的なスーパーセットです。もともとは、.NETまたは他の言語を使用する開発者がVSが.NET Frameworkで優れたラッパーを作成するのを待たずに、WinRTAPIを簡単に呼び出せるようにする方法という1つの問題に対処するために設計されました。

次に、APIライブラリがあります。私たちはここでいくつかの素晴らしいことといくつかの愚かなことをしました。非同期のもののいくつかに少し夢中になっているかもしれません。 C ++ / WinRTでプログラミングすると、これを大幅に軽減できます。 UIスレッドを使用していない場合は、結果を取得するだけで、ブロックされ、同期して完了します。 .NETでもこれが簡単になるかもしれませんが、最近は.NETコードの記述が少なくなり、現在の状況について確信が持てなくなりました。計画どおりに機能しなかった他のいくつかのことも行いました。それらすべてをリストすることはしません。ただし、いくつかの改善を行いました。

UWPアプリケーションモデルは、両足でWindowsに飛び込みました。つまり、OS APIを一度作成すれば、JSベースのアプリ、.NETアプリ、ネイティブアプリから簡単にアクセスできるようになります。それ自体が良かったです。他のすべてのWin32APIを取り除くことは、それほど良くありませんでした。まだやるべきドキュメント作業がいくつかありますが、ストアアプリで使用できるはるかに多くのクラシックなWin32APIがあります。簡単に言うと、新しいデバイス上に小さなユーザーベースを持つまったく新しいアプリプラットフォームを作成しましたが、既存のコードを持ち込むことはできず、多くの人が現れませんでした。私たちは知っています。そのため、少しずつ修正しています。私たちも多くのことを正しく理解し、両方の世界の最善のアプローチに向けてゆっくりと、しかし着実に取り組んでいます。宣言型インストールシステムは、ほとんどの点で素晴らしいものです。

このスレッドでは、UWPアプリとデスクトップアプリ間のコードの移植性についても触れました。 UWPモデルは大きく分岐しているため、いくつかの問題点があります。できるだけ早くそれらに対処しています。時間がかかるものや、「大きな休憩」が必要なものもあります。たとえば、CRTDLLには異なる名前を使用します。緩和策であるVCフォワーダーパッケージをまとめましたが、実際の修正は、CRTの将来のバージョンで区別を最終的に削除することです。これには、本質的にファイルの名前の変更と大幅な重大な変更が必要です。混乱を招くため、意図的にこれを行うことはめったにありません。

WinRT自体は、ツールのオープンソースをますます動かしており、あまり知られていませんが、ほとんどのWinRTはデスクトップアプリで利用できます。 XAMLは大きなギャップでした。 XAMLアイランドは正しい方向への一歩でしたが、私はWinUIにはるかに興奮しています。

特定のAPIに関するフィードバック

これらの多くについて、これが問題である場合はフィードバックを提出するようお願いします。問題を適切なチームに宣伝するお手伝いをします。 Windowsのさまざまなチームがそれぞれ独自のAPIを担当しており、フィードバックハブにファイルする場合に最も効果的です。これは、フィードバックを実際の人間と物語に結び付けます。また、フィードバックを追跡することもできます。他の人が適切に提出するフィードバックに追加することで、お互いに少し助け合うことができます。適切なカテゴリを選択してみてください。明確でない場合は、「開発者フィードバック」-> APIフィードバックを使用できます

BroadSystemAccess API /機能は、実装されているため実用的ではありません。

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
フィードバックハブアイテムを送信して、リンクを送ってください。私はそれを個人的に宣伝し、適切な所有者に渡します。 80％のフォールオフ率は良くありません。それがユーザーにとっても危険信号であるという点を理解しています。ファイルAPIが十分に高速だった場合、将来のアクセスリストは少なくとも一部の問題を軽減するように思われますが、現在のように「滑らか」ではない可能性があります。しかし、その後、あなたは岩と困難な場所の間にいます。今のやり方で魔法をかけるには、ユーザーにすべてを見せてもらう必要があります。彼らのパスワードスプレッドシート、彼らのメールフォルダ、彼らのブラウザキャッシュなど。あなたは信頼できるかもしれませんが、あなたのアプリはユーザーに一時停止させ、彼らが彼らの世界を引き渡す前にあなたをどれだけ信頼しているかを考えさせるべきです。

アプリを閉じて再起動するというアイデアは厄介なステップであることを理解しています。これは、少なくとも最初の起動時に整理する必要があるタイプのようです。別のフィードバック項目を提出してください。同じオファー。宣伝してお届けします。

将来のアクセスリストがサブフォルダーにアクセスできるかどうかに関して、私は先に進んで、ページのドキュメントの問題を作成しました。 https://github.com/MicrosoftDocs/windows-uwp/issues/2322。ドキュメントページはgithubにあるため、ドキュメントに問題を報告したり、コンテンツの変更を提案したりできることは注目に値します。

ファイルをアプリにドラッグすると、書き込みアクセスが許可されません。フィードバックハブについても同じです。提出してください、そうすれば私はそれに応じてルーティングします。

MSストアの外部でサイドローディングするためのアプリを作成する

私がここで得たポイントは、問題のモックはドキュメントの問題であるということですが、それは別の重要な側面に触れています。一部のツールがgithubプロジェクトとオープンソースに移行したため、ドキュメントも一緒に移動しました。そのため、Windowsドキュメントをすべてのワンストップショップとして使用することが難しくなっています。 .appinstallerファイルに関する特定の問題に関してこの問題を社内で提起し、これに適切に対処する方法についてコンテンツチームとより一般的に話し合います。

また、デバッグするためにサーバーを経由してルーティングする必要があるという特定の問題についても言及しました。既存のgithubプロジェクトに対する問題として提出する必要があること。

新しい証明書の発行とプライベート配布

これは私から少し家に近いです（私のより大きなチームはアプリケーションのインストールの側面も処理します。私が作業できるこれに関するフィードバックハブの問題に感謝します。

WinRT型システムは、優れたAPIとライブラリを提供する機能に影響を与えます

タイプ名をオーバーロードできないのは仕様によるものです。 javscript（Node / V8はどうですか？それは面白いでしょうか？）アプリがWinRT APIにアクセスする方法を再考するまで、これを再検討する準備はできていません。プロパティとNaNに関する他の問題は、いくつかの良い議論がある別の問題にあるので、この応答ではそれに踏み込みません。

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプトを表示する必要があります

ええ、私はそれを+1します。提出してください。アプリの下のフィードバックハブには…フィードバックハブのカテゴリがあります。それはとてもメタです。

非同期APIはまだ手に負えないので、非同期であってはならないものには扱いにくいようです

うん。これは、社内でも引き続き議論の的となっています。私たちがまだ十分にヒットしていない、うんざりすることと良い行動を奨励することの間には、いくつかの微妙なバランスがあります。同期させたい特定のAPIに関するフィードバックを引き続き提出してください。

WinRTには優れたオーディオAPIはありません

私はオーディオの専門家ではありません。フィードバックハブに気軽にファイルしてください。ただし、ここでライフラインを呼び出して、質問をします。

クリップボードの痛み

ここではメイカルパから始めなければなりません。私たちのクリップボードアクセスモデルは、ユーザーを非常に保護していたWin8の時代に設計されました。私はそれのほとんどをコーディングしました。クリップボードを保護するのには十分な理由があります。ユーザーはあらゆる種類の機密データをクリップボードに置きますが、クリップボードを上書きできるアプリは、より多くのアクセス権を持つ可能性のある他のアプリの弱点を悪用しようとすることで害を及ぼす可能性もあります。 Win32クリップボードAPIは、悪用される可能性のある非常に強力な動作も可能にします。したがって、クリップボードは、アプリがフォアグラウンドにあるかデバッガーに接続されていない限りアクセスを制限し、クリップボードに置くことができるものを少し厳しくします（実際に試しているのでない限り気付かない方法で）。

とはいえ、操作中の通知はクリップボードへのアクセスを許可する必要があるようです。これには、ウィンドウとフォアグラウンドのカウント方法のために特別な処理が必要になると思いますが、合理的ではないようです。 APIフィードバックの下でファイルしてください。その問題をバグデータベースにも宣伝します。

まとめ

お役に立てば幸いです。スレッドを追跡し、上記の問題が提出された場合は、上記の問題をフォローアップします。

すでに多くのことを手にしているWinUIチームへの敬意から、このスレッドを終了させて、このスレッドで提起されたWinUIとウィンドウ処理の側面だけに焦点を当ててください。これは非常に長く曲がりくねっているので、それらを別々の小さな問題にまとめると役立つ場合があります。フィードバックを提出し、リンク付きのコメントをドロップできるように、これを数日間開いたままにしておきます。その後、このスレッドを閉じます。

WinRT型システムの議論をさらに詳しく知りたい場合は、xlangプロジェクトから始めるのがよいでしょう。特定のWindowsAPIの動作については、フィードバックハブの方が適しています。現在、コメントシステムもあるので、それが役立つことを願っています。

すばらしい議論と、非常に多くのトピックに関するすべての詳細なフィードバックに改めて感謝します。

ベン・クーン
マイクロソフト

BenJKuhn 2020年03月27日

❤6 👍6

ユーザーがアプリへのアクセスを許可する対象を選択できるファイルピッカーを提示した場合、アプリは閉じません。

これがユーザーとしてどれほど重要かを強調することはできません。アプリにすべてへのアクセスを許可したくはありませんが、奇妙な場所を要求した場合は、アクセスを許可します。

sharpninja 2020年03月27日

👍2

@BenJKuhn詳細な回答をありがとう。とても感謝しています！

•WPF。私はWPFと愛憎関係にあります。それは便利で、ほとんどが良いです。ファイルピッカーのネストされたクリックに関するコメントを読んだとき、それは私を笑わせました。 WPFにはいくつかの癖があり、それが私に本当の頭痛の種を与えているからです。 WPFでドラッグすると、ドラッグメッセージがネストされたメッセージで二重にディスパッチされることがあるため、実際にはモーダルドラッグ内でモーダルドラッグを実行しています。通常、気付くことはありません。いつもの。しかし、私はまだWPFが好きです。 😉

全くもって同じ意見です。私はWPFの支持者ではありません。かなり前に、WPFの限界に達しました。それが私がUWPに移行した理由です。安定性に関しては、WPFの方がはるかに安定しているようです。

WinRT vs. UWP vs. .NET –いくつかの背景

次に、APIライブラリがあります。私たちはここでいくつかの素晴らしいことといくつかの愚かなことをしました。非同期のもののいくつかに少し夢中になっているかもしれません。

あなたはそれをもう一度言うことができます:)

UWPアプリとデスクトップアプリ間のコードの移植性もこのスレッドで触れられました[...]が、実際の修正は、CRTの将来のバージョンで区別を最終的に削除することです。これには、本質的にファイルの名前の変更と大幅な重大な変更が必要です。。

ETAはありますか？ .Net 5？

最新のアプリのファイルシステムAPIは、痛々しく、予想外に遅い
https://docs.microsoft.com/answers/questions/608/please-ether-allow-systemio-all-over-hdd-or-drast.html
このフィードバックは、お客様とアプリケーションを構築している私たちのチームの両方から聞いています。現時点でもっと共有できるものがあればいいのにと思います。今のところ、残念ながら私が言えるのは「私たちが知っている」ということだけです。

これまでのところ、回避策があります-理想からはほど遠いですが、今のところ大丈夫です-https ： //github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

BroadSystemAccess API /機能は、実装されているため実用的ではありません。
https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
フィードバックハブアイテムを送信して、リンクを送ってください。私はそれを個人的に宣伝し、適切な所有者に渡します。 80％のフォールオフ率は良くありません。わかりました

私は週末にそれを手に入れたいと思っています。

それがユーザーにとっても危険信号であるという点。ファイルAPIが十分に高速だった場合、将来のアクセスリストによって少なくとも一部が軽減されるようです。

はい、StorageFile / Folder APIがSystem.IO（または少なくとも同等）と同じくらい高速である場合、それはそれを軽減します。それは試してみることの欠如のためではありません-私はドキュメントで概説されているすべてを行いました。

痛みがありますが、現在のように「滑らか」ではない可能性があります。しかし、その後、あなたは岩と困難な場所の間にいます。今のやり方で魔法をかけるには、ユーザーにすべてを見せてもらう必要があります。彼らのパスワードスプレッドシート、彼らのメールフォルダ、彼らのブラウザキャッシュなど。あなたは信頼できるかもしれませんが、あなたのアプリはユーザーに一時停止させ、彼らが彼らの世界を引き渡す前にあなたをどれだけ信頼しているかを考えさせるべきです。

私はこれをすべて完全に理解しています。そして、私はあなたに同意します。私の問題点は、これらすべての現在の実装です。私はすでにこれを扱うUIのほとんどを書き直しました（数回）。

そうは言っても、ここに改善のための私の考えがあります：

「フォルダの選択」はもう少し役立つかもしれません-興味のあるファイルを指定して、それを含むフォルダをユーザーに強調表示することができます
クリップボード-ユーザーがいくつかのファイル/フォルダーをクリップボードに入れてからアプリに戻ると、自動的にそれらにアクセスできるようになります（おそらく、「ClipboardFilesAndFolders」機能を追加できます）
ファイル/フォルダーのドラッグアンドドロップ-これらのファイルへのアクセスを自動的に許可する必要があります（それ以外の場合、ユーザーがアプリにファイルをドロップするのはなぜですか？）

アプリを閉じて再起動するというアイデアは厄介なステップであることを理解しています。これは、少なくとも最初の起動時に整理する必要があるタイプのようです。別のフィードバック項目を提出してください。同じオファー。宣伝してお届けします。

了解しました、ありがとう-週末に。

ファイルをアプリにドラッグすると、書き込みアクセスが許可されません。フィードバックハブについても同じです。提出してください、そうすれば私はそれに応じてルーティングします。

そうです、ファイルをアプリにドラッグすることについてです。私はまだ実際にそれを試していません：

ファイルとフォルダの両方で機能しますか？
.Pathにアクセスできますか？
それは永続的ですか（私はそうではないと思います）？
StorageFile / Folderを保持する必要がありますか、それとも後で.Pathから再作成する必要がありますか（2.の答えがYESであると仮定）？

MSストアの外部でサイドローディングするためのアプリを作成する
私がここで得たポイントは、問題のモックはドキュメントの問題であるということですが、それは別の重要な側面に触れています。一部のツールがgithubプロジェクトとオープンソースに移行したため、ドキュメントも一緒に移動しました。そのため、Windowsドキュメントをすべてのワンストップショップとして使用することが難しくなっています。 .appinstallerファイルに関する特定の問題に関してこの問題を社内で提起し、これに適切に対処する方法についてコンテンツチームとより一般的に話し合います。

ええ、それは素晴らしいでしょう！

個人的に、私は自分のアプリのためにそれを理解しました。それは私がやりたい他のいくつかの高度なことをするのを妨げています（たとえば、.appinstallerファイル全体をどのように変更する必要があるのか心配なので、win32アプリを起動する必要があります）。

しかし、私にとって、これはVisualStudioの「公開」プロセスの一部である必要があります。 .appinstallerを作成する必要があります（これらの依存関係の名前をすべて正しく取得することは簡単ではなく、依存関係の更新は->ここでもう一度行います）。また、readme.txtファイルを作成する必要があります。このファイルには、サーバーにアップロードする必要があるものが説明されており、.appinstallerをローカルで使用できないため、サーバーからダウンロードする必要があります（テスト時））

また、デバッグするためにサーバーを経由してルーティングする必要があるという特定の問題についても言及しました。既存のgithubプロジェクトに対する問題として提出する必要があること。

その問題が何だったのか覚えていません:)

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプトを表示する必要があります
ええ、私はそれを+1します。提出してください。アプリの下のフィードバックハブには…フィードバックハブのカテゴリがあります。それはとてもメタです。

右：）

非同期APIはまだ手に負えないので、非同期であってはならないものには扱いにくいようです
うん。これは、社内でも引き続き議論の的となっています。私たちがまだ十分にヒットしていない、うんざりすることと良い行動を奨励することの間には、いくつかの微妙なバランスがあります。同期させたい特定のAPIに関するフィードバックを引き続き提出してください。

ふふ、それは大げさなリストです;）

StorageFolder / Fileの基本的なプロパティから始まります。 StorageFile.GetFileFromPathAsync（+フォルダーの場合も同様）。
サムネイルの読み込み（StorageFile.GetThumbnailAsync
ビットマップのロード。これは他のライブラリ（win2dなど）に持ち込まれ、単純なビットマップの読み込み（20ミリ秒未満）のように、5秒ほど続くという非常識なしきい値に達したため、特に苦痛です。明らかに舞台裏でいくつかのロックがありますが、誰も何を/なぜ/いつかはわかりません。そして、ええ、私のラップトップはロケットです。

私は他の多くのAPIを追跡していません。私のプロジェクトをすばやく検索すると、326の使用法が示されます。私の側の多くのものを同期する必要があるため、これを大幅に削減しました。

上記は私の頭のてっぺんからの私の主なトップの痛みです。これから、ドキュメントを作成して追加します:)

WinRTには優れたオーディオAPIはありません
私はオーディオの専門家ではありません。フィードバックハブに気軽にファイルしてください。ただし、ここでライフラインを呼び出して、質問をします。

これが解決されるかどうか/どのように解決されるかはわかりません。最も簡単なのは、要件などを緩めて、naudio（https://github.com/naudio/NAudio）をUWPに適切に移植できるようにすることです。明確にするために、それは箱から出してUWPにコンパイルできますが、ユーザーの役に立つもののほとんどが＃ifdefされているので、それは役に立ちません。

明確にするために、私はUWPのサウンドAPIについて不満を言っていません-これはまったく問題ありませんが、もっと必要です。つまり、音波などを解釈する機能（naudioが許可する）。

私はnaudioの移植を行いました。そこでは、すべての#ifdefをほとんど削除しました-それは機能しますが、私のアプリはMSストアに入ることができません-そして私はそれで大丈夫です。

クリップボードの痛み

[...]とはいえ、操作中の通知はクリップボードへのアクセスを許可する必要があるようです。これには、ウィンドウとフォアグラウンドのカウント方法のために特別な処理が必要になると思いますが、合理的ではないようです。 APIフィードバックの下でファイルしてください。その問題をバグデータベースにも宣伝します。

良さそうですね。

ありがとう！

jtorjo 2020年03月27日

@jtorjoファイルシステムに関するフィードバックハブアイテムに問題＃1893（提案：ファイルシステムアクセス：特定のファイルの場所にアクセスするためのアクセス許可を要求するためのユーザーフレンドリーな方法を提供する）も含めてはあなたが上記の根本的な問題をリストしたと

もちろん、フィードバックハブに追加するのが不便な場合は、ファイルします。

Felix-Dev 2020年03月27日

@ Felix-Dev頑張ります！あなたを投稿し続けます！

jtorjo 2020年03月27日

👍1

ファイルをアプリにドラッグすると、書き込みアクセスが許可されません。フィードバックハブについても同じです。提出してください、そうすれば私はそれに応じてルーティングします。

そうです、ファイルをアプリにドラッグすることについてです。

これは実際には、シェルのコンテキストメニューから開くことについてのメモであるはずでした。混乱させて申し訳ありません。

BenJKuhn 2020年03月27日

@BenJKuhnこのGithubリポジトリは、フィードバックハブの場所よりも特定のWinRT提案について話し合うのにはるかに適した場所であることに照らして（過去12か月間にこのリポジトリで複数回表明された開発者の感情に基づく）：投稿するだけで問題ありませんこのリポジトリにあるはるかに詳細な提案へのリンクを含むフィードバックハブの簡単な提案の概要（今のところ、私が知っている開発者コミュニティの信頼を持っている特定のUWPアプリモデルフィードバックプラットフォームがないため）？ここでは、他のコミュニティの意見を取り入れて提案がさらに洗練されているのを見てきました。そのため、マイクロソフトの特定のチームは、開発中の提案に直接リンクできます。

Felix-Dev 2020年03月28日

@ Felix-Dev特定の提案については、「開発者プラットフォーム> APIフィードバック」というタグが付けられたフィードバックHubに送信するのが最善だと正直に思います。

そのフィルターの下で提出された最近のフィードバックを見ると、あまり具体的なフィードバックが追加されていないようです。そのフィルターの下に提出されたアイテムは（最大で）30個しかありませんでした。しかし、エンジニアは最近そこでフィードバックに応えています。

上記のタグが付いているように、フィードバックハブを介してAPIフィードバックを提出するようコミュニティに呼びかけています。提案が改善されたら、APIフィードバックを送信するオプションとしてそれが繁栄するようになります。

@BenJKuhnは私に同意すると思います。

duke7553 2020年03月28日

👍1

応答がかなり長くなっていることに気づいたので、これを事前の警告として受け取ってください😅

@ duke7553ここでは、コミュニティがUWPプラットフォームのフィードバックに2つの異なるプラットフォームを使用する必要がある状況があります。（パラメータxをメソッドyに追加するか、メソッドを追加してzを実行してください）などの特定のAPIリクエストは、少なくともフィードバックハブに提出する必要があります（ただし、おそらく別の場所にも投稿する必要があります）。ただし、それよりも複雑な問題/提案（UWPのコアに至るまで）プラットフォームは、フィードバックハブ以外の場所に現在の形式で確実に投稿する必要があります。フィードバックハブに短い要約を投稿するのは問題ありませんが、それ以外の場合は、フィードバックハブは現在のプラットフォームではありません。理由の詳細については、以下をお読みください。

現在の状態では、フィードバック・ハブは、もう一度、Twitterの

Windows Devチームによる（認識された）関与の欠如（最近提出されたAPIフィードバックも確認しましたが、現時点では、特に2か月の問題に関して、コメントが0、公式の返信が0の問題が多数表示されています。古い）。
特定の問題/提案に対するコミュニティの関与は非常に低いです（賛成票、コメント）。
フィードバックハブの全体的なUI / UXは、チームやコミュニティとの魅力的なフィードバックの議論を行うことを非常に困難にします。これに関して、WinUIチームの一部の人々は、ここのコミュニティにも同意すると述べました。
最後に、Githubでは、画像やGIFなどのサポートメディアファイルをプロポーザルに追加して視覚化するのが非常に簡単です。問題を提出するときに、フィードバックハブから直接取得したこの画像をここに残しておきます。

以前はFeedbackHubを使用して開発プラットフォーム固有の問題を提出していませんでしたが、現在、コミュニティがどのように問題を受け取っているか（コミュニティの関与はほぼゼロです！）、Windows開発チームとその全体的な構造を確認しています。この単一のWinUIリポジトリは、基本的にすべての面でフィードバックHubよりも優れています（提案の作成のしやすさ/コミュニティの関与/ MS開発者の可用性/ ...）。

正直なところ、それは近くさえありません。

特にコミュニティの関与に関しては。ここでのこのリポジトリでのコミュニティの意見がどれほど例外的であり、非常に多くの問題/提案を大幅に前進させ、改善してきたかを十分に強調することはできません。 現在のフィードバックハブだけに提出すると、コミュニティからのすばらしい意見はすべて失われます。

そして、ここで作成した私のUWPアプリモデルの問題の開発チームによって応答については、私はこれを言うだろう：のような多くの場合、この1私は作業項目が内部的に作成されていることに注意してくださいとのタイムリーなフィードバックを得ました。これ以上何を求めることができますか？フィードバックハブに提出した場合、問題がどこにも行かないと感じている多くの開発者の感情とは対照的です。そして、今フィードバックハブを見るだけで、それらがどこから来ているのかがわかります。

@BenJKuhn
MSのチームは、UWPフィードバックプラットフォームを真剣に強化する必要があります。これらの改善が見られるまで、WinUIチームによって許可されている限り、ここでも常にこのリポジトリを使用します。フィードバックHubは現在、多くのWindows開発者の目には底堅い立場にあり、一晩の投稿でその状況が突然変わることはありません。これは始まりですが、フィードバックHub（または以前にシャットダウンされたUserVoice for UWPなどの他のMS固有の開発者フィードバックプラットフォーム）について話すときに多くの開発者が受ける否定的な印象を根本的に元に戻すには、さらに多くのことが必要です。多くのUWP / Windows開発者がフィードバックハブやその他の過去のフィードバックプラットフォームを扱うときに得た多くの残念な経験を考えると、私は-この問題に関して-Windows開発者とフィードバックチームは開発者に懇願するのではなく、何よりもまずステップアップする必要があると強く信じています戻ります（表示する改善が見られる場合は、それほど多くはありません）。これは非常に厳しい見方だと思いますが、このリポジトリや他の多くのフィードバックプラットフォームで長年にわたって提供された開発者による多くの回答を実際に見ると、開発コミュニティに本当のフラストレーションがあることが簡単にわかります。

マイクロソフトと開発者コミュニティの両方に高い満足度を提供する活気に満ちた実り多いフィードバックプラットフォームを作成するには、双方がお互いを必要とするため、ここで厳しくする必要はありません。妥協案として、上記の投稿でUWPの問題をこのリポジトリに投稿し、コミュニティと積極的に話し合い、フィードバックハブに含まれているgithubスレッドへのリンクを含む短い要約を投稿することを提案しています。上記のコミュニティにもたらすすべての利点に加えて、追加されたリンクにより、Windows Devチームは、このコミュニティに存在するさまざまなビューを確認でき、おそらく提出されないであろう多くの小さなアイデアを見つけることもできます。フィードバックハブにありますが、ここのコメントの多くで見つけることができます。

この投稿は、FeedbackHubの開発者プラットフォーム-> APIフィードバックセクションから取得したスクリーンショットで終了します。

PS：この投稿を使用して、WinUIチームが、WinUIとはまったく関係のない問題をホストするためにリポジトリを開くことにますが、代わりに、開発者がUWPで見ている基本的な問題に対処することを目指します。 WinUIチーム、ありがとうございました！

Felix-Dev 2020年03月29日

👍2 😄1

@BenJKuhn

これが私が作成したフィードバックハブの問題です

BroadSystemAccess API /機能は、実装されているため実用的ではありません。 https://aka.ms/AA804aq

BroadSystemAccess API /ユーザーが広範なシステムアクセスを許可している場合はアプリを再起動しないでくださいhttps://aka.ms/AA7zpe3

クリップボードは常に機能するはずです。 https://aka.ms/AA804ce

ファイルシステムアクセス：特定のファイルの場所にアクセスするためのアクセス許可を要求するためのユーザーフレンドリーな方法を提供しますhttps://aka.ms/AA804cp（@ Felix-Devの場合）

WinRTには優れたオーディオAPIはありませんhttps://aka.ms/AA804d0

非同期APIはまだ手に負えないので、非同期であってはならないものには扱いにくいようですhttps://aka.ms/AA804d3

私が作成した他のもの

詳細-より多くの文字を許可する必要がありますhttps://aka.ms/AA7zws5

カテゴリを選択してください-これを簡単にし

よくわからないこと

ファイル/フォルダのドラッグアンドドロップ-私はそれを個人的にテストしていません。つまり、実装がそれほど難しくないドラッグアンドドロップ部分については興味がありません。ユーザーがUWPコントロールにファイル/フォルダーをドロップしたときに実際に機能するかどうか知りたいです。読み取り専用アクセス権はありますか（これで十分です）？これらのファイル/フォルダーをFutureAccessListに追加できますか？

オンラインにはそれほど多くの情報がないので、誰かがこれをうまくテスト/使用したかどうか興味があります。

フィードバックハブ

フィードバックハブは快適な体験ではありません。一つには、私が追加した問題はしばらくの間「私のフィードバック」に表示されません-私はアプリを閉じて再起動する必要があります。私の最後の選択を覚えていません。あまり多くのテキストを書くことができず、ファイルやクリップボードの画像をドロップする方法もありません。だから私は@ Felix-Devに完全に同意しています-問題をどこに投稿するかを理解するのは本当に難しいです（これからはxlangに投稿します）。

jtorjo 2020年03月29日

👍2

@BenJKuhnユーザーが操作したときにクリップボードにアクセスできる特定のトースト通知問題のフィードバックHubリンクは次のとおりです： https ：

Felix-Dev 2020年03月29日

素晴らしい議論をありがとうございました。私はあなたが提出したプラットフォームの問題のそれぞれを適切なチームにルーティングしました。それに応じて期待を設定するために、就職活動から類推を引き出しましょう。それは、採用プロセスでスクリーニングを通過し、面接に直接進むようなものです。ここから、各問題は調査と優先順位付けを行う適切なチームの手に委ねられます。

これらの問題を報告するためにあなたが行った努力に感謝し、チームがそれらをレビューする間、それらを追跡し続けます。皆様が直面する問題について引き続きご協力いただければ幸いです。また、Windowsでのアプリケーション開発者のエクスペリエンスを向上させるために最善を尽くします。

ありがとう、

ベン・クーン

BenJKuhn 2020年03月30日

❤3 🚀1

@jtorjo作成したNAudioのUWPポートのWACKレポートを共有できますか？

このデータは、NAudioがストア認定を通過できるようにするために緩和する必要がある制限を評価するのに役立ちます。

mikebattista 2020年03月31日

@mikebattistaWACKを付けました。 naudioの問題のみを考慮してください。

明らかに、log4netをフォークしてそれらの呼び出しを削除することで問題ないと思いますが、log4netの問題も解決するのがクールです。しかし、実際に呼び出されることはないと確信しているので、それらが表示されるのは奇妙です。ともかく...

FindFirstFileExFromApp-これは必要です（そして実際に存在します）-絶対にフラグを立てるべきではありません。

EnumChildWindows / EnumWindowsは無視できます-私はそれらを#ifdefすることができます。

ValidationResult.zip

jtorjo 2020年04月01日

ありがとう！サポートされているAPIの失敗を評価します。私はオーディオチームに連絡を取り、ここでの制限を緩和する可能性について意見を求めました。

mikebattista 2020年04月01日

🚀1

@mikebattista素晴らしい、ありがとう！これをとても楽しみにしています:)

jtorjo 2020年04月01日

ドラッグアンドドロップシナリオに関する@jtorjo ：

ファイルとフォルダの両方で機能しますか？
多くのアプリやテストでそうすべきであり、そうです。そうでない場合は、バグを報告してください。
.Pathにアクセスできますか？
たぶん-ストレージアイテムをバックアップするための実際のファイルシステムパスがある場合は、はい。（シェルライブラリのようなものは実際には実際のファイルシステムパスを持っていません）
それは永続的ですか（私はそうではないと思います）？
いいえ、アプリはそれを将来のアクセスリストに追加することで永続化できます。
StorageFile / Folderを保持する必要がありますか、それとも後で.Pathから再作成する必要がありますか（2.の答えがYESであると仮定）？
これを[将来のアクセスリスト]または[最近使用したリスト]に追加する必要があります。そうしないと、その1つのオブジェクトインスタンスを介したアクセスのみが可能になります。そのインスタンスを解放すると、アクセスが失われます。

任意の場所からのビデオファイルの追加に関して-システムは意図的に任意のアクセスを許可していませんが、アプリが別の場所に配置されたファイルの一般的なケースを処理することは可能であり、ユーザーはそれらを含めるようにライブラリを更新していません。インデクサーとストレージセンスサービスの両方に、ドライブを定期的にスキャンして詳細（ファイルのサイズなど）を確認するコードが含まれており、写真やビデオファイルを見つけるために利用されます。アプリはStorageLibraryAPIを使用して、ライブラリにまだ存在しないそのような場所が見つかったかどうかを判断し、見つかった場合は、ユーザーにそれらを追加するように求めることができます。（これにより、ユーザーが責任を持ち、一般的なシナリオが可能になります）ファイルを含むすべての場所が自動的に追加されることはありません。これは、それが正しいことであるかどうかを判断する方法がないためです。 [私は多くの3Dモデル構築およびレンダリングツールを使用しており、たとえば、写真ライブラリに表示したくない文字通り何千ものテクスチャ画像を持っています]

「FindFirstFileExFromApp-これは必要です（そして実際に存在します）-絶対にフラグを立てるべきではありません。」
* FromApp APIはすべて、アプリコンテナアプリでの使用を目的として設計および意図されていることに完全に同意します。したがって、ツールがそれらのいずれかにフラグを立てている場合、それは対処する必要のあるバグです。

smaillet-ms 2020年04月02日

@ smaillet-msここで返信していただきありがとうございます。 Windows.Storage APIの速度を改善するための作業が行われていますか？私たちは長い間答えを待っていました。アプリのシナリオで改善されたAPIを使用するために、NDAに署名したいと思います。

現在、FindFirstFileのFromApp実装を使用していますが、FromAppAPIを使用してアイテムのサムネイルを取得することはできません。

Windowsランタイムを改善するために行われている作業に関するこのレベルの機密性は、以前にスレッドでMicrosoftエンジニアによって共有されていたものとは対照的です。

関連する無視されたフィードバックリンク： https ：

duke7553 2020年04月02日

👍2

ただ、ここで追加し、具体的な詳細はNDAの後ろに保護されるかもしれないが、このトピックで行われている作業があるかどうか、我々が見ることを期待することができたときにMSが公に一般的な見通しと一緒に（これを述べるかどう内部的には、UWPの多くの開発者を安心させるだろう/もっと聞く）。

Felix-Dev 2020年04月02日

👍2

OSのいくつかのリリースにわたって、ストレージAPIのパフォーマンスを改善するために多くの作業が行われてきました。開発者にとってのこの時点での課題は、主に、どのAPIをいつ使用するかを知ることです。

物事を行うには多くの方法があり、それらの多くは特定のアプリケーションにとって完全に間違っています。残念ながら、それは実際にはアプリケーションと、ファイルシステムから取得した情報をどのように処理するかに依存するため、「1つの正しい正解」はありません。 * FromApp APIは現在、標準のWin32APIと比較して最高のパフォーマンスを提供します。ここで指摘したように、サムネイルなどの追加のシェルデータがすべて含まれているわけではありません（キャッシュで利用できない場合、実際に取得するにはコストがかかります）。そのため、アプリが名前/パスまたは拡張子に基づいて対象のファイルを検索する必要がある場合は、* FromApp APIを使用して検索できます。次に、名前に基づいてStorageFileを作成し、詳細を取得します。その中には重複したオーバーヘッドがありますが、この場合はアクセスチェックが2回実行されるためです。 1つのファイルだけを見つけようとしている場合、それは多くの場合問題ではありませんが、大規模な冗長性にはコストがかかる可能性があります。 Windows.Storage.Search.IndexerOption.OnlyUseIndexerAndOptimizeForIndexedPropertiesでStorageWinRT Apiを使用すると、非常に高速な列挙を取得できます。これは、オンデマンドで完全に実現されたストレージアイテムにフォールバックします。これは、パフォーマンスヒットがありますが、アイテムの作成よりも低くなります。追加のアクセスチェックを含める必要があるため、パスから。欠点は、ユーザーが問題の場所のインデクサーを無効にした場合は機能しないことです。

写真/メディアタイプのアプリのようにUIにデータを入力する場合は、仮想化などのUIでの使用シナリオを対象としているため、BulkAccessクラスがおそらく最善の策です。これにより、UIにデータをすばやく提供し、より多くのデータをフィードできます。ユーザーがコンテンツをスクロールするときに、必要に応じて。

私が言ったように、多くのトレードオフがあります。明らかに、特定のアプリに最適なものを評価するプロセスを文書化する方法を理解するために行うべき作業があります。また、既存のアプリを壊すことなく、最大の一般的な改善を達成できる場所の評価も続けています。

WinRTは大きな表面であり、MSの単一のチームによって所有されていません。各チームはリリースごとに優先順位を評価し、事前に計画を公開する場合としない場合があります。個人的には、アプリコンテナの内外でWin32APIに関してゼロオーバーヘッドが発生する場所に到達することを望んでいます。明らかに、私たちはその時点ではなく、そこに到達することを約束することはできません。ビジネスの優先順位と、Windowsと同じくらい大きなプロジェクトで、エンドユーザーの数が多いプロジェクトは、困難/困難を伴う複雑なプロセスです。すべてのレベルでの選択。（邪魔になる可能性のあるさまざまな技術的課題は言うまでもありません...）

smaillet-ms 2020年04月03日

👍3

@ smaillet-ms

ドラッグアンドドロップシナリオに関する@jtorjo ：
ファイルとフォルダの両方で機能しますか？
多くのアプリやテストでそうすべきであり、そうです。そうでない場合は、バグを報告してください。
.Pathにアクセスできますか？
たぶん-ストレージアイテムをバックアップするための実際のファイルシステムパスがある場合は、はい。（シェルライブラリのようなものは実際には実際のファイルシステムパスを持っていません）
それは永続的ですか（私はそうではないと思います）？
いいえ、アプリはそれを将来のアクセスリストに追加することで永続化できます。
StorageFile / Folderを保持する必要がありますか、それとも後で.Pathから再作成する必要がありますか（2.の答えがYESであると仮定）？
これを[将来のアクセスリスト]または[最近使用したリスト]に追加する必要があります。そうしないと、その1つのオブジェクトインスタンスを介したアクセスのみが可能になります。そのインスタンスを解放すると、アクセスが失われます。

いいですね。いつか私のアプリにこれを実装します。

[...]インデクサーとストレージセンスサービスの両方に、ドライブを定期的にスキャンして詳細（ファイルのサイズなど）を確認するコードが含まれており、写真やビデオファイルを見つけるために利用されます。アプリはStorageLibraryAPIを使用して、ライブラリにまだ存在しないそのような場所が見つかったかどうかを判断し、見つかった場合は、ユーザーにそれらを追加するように求めることができます。

私はこれに反対するものは何もありませんが、これは私のアプリに追加の複雑さを感じます。実際にこれを使っている人のことを聞いたことがありますか？

今のところ、StorageFolder / Fileに関しては、あらゆる種類の問題に対処するための1000の方法を理解する必要がありますが、これは単なる追加の1つです。繰り返しになりますが、開発者である私に負担をかけるだけです。

「FindFirstFileExFromApp-これは必要です（そして実際に存在します）-絶対にフラグを立てるべきではありません。」
* FromApp APIはすべて、アプリコンテナアプリでの使用を目的として設計および意図されていることに完全に同意します。したがって、ツールがそれらのいずれかにフラグを立てている場合、それは対処する必要のあるバグです。

同意しました。

jtorjo 2020年04月03日

@ smaillet-ms

OSのいくつかのリリースにわたって、ストレージAPIのパフォーマンスを改善するために多くの作業が行われてきました。開発者にとってのこの時点での課題は、主に、どのAPIをいつ使用するかを知ることです。

申し訳ありませんが、これはあまり安心できることではありません。

WPFの時代には、System.IOを使用し、必要なファイル/フォルダークエリを非常に簡単な方法で実行し、速度についてはまったく心配していませんでした。私はただ知っているでしょう-それは機能します。 4000ファイル、10000ファイル-それは単に機能します。

物事を行うには多くの方法があり、それらの多くは特定のアプリケーションにとって完全に間違っています。

それはほとんど言います-APIはそもそも存在するべきではありません。

残念ながら、それは実際にはアプリケーションと、ファイルシステムから取得した情報をどのように処理するかに依存するため、「1つの正しい正解」はありません。 * FromApp APIは現在、標準のWin32APIと比較して最高のパフォーマンスを提供します。

それは確かに真実です。 * FromApp APIを使いやすいクラスでラップしましたが（私自身のシナリオでは）、これもMSが行うべきことです-これを使いやすいAPIで提示します-シンプルなC＃ラッパーユースケースの98％をカバーしている可能性が非常に高いです。

自分でやるのですが、時間がありません。簡単なクラスを楽しく共有でき、そこから誰かが受講できます。

ここで指摘したように、サムネイルなどの追加のシェルデータがすべて含まれているわけではありません（キャッシュで利用できない場合、実際に取得するにはコストがかかります）。

同意しました-私はすでにこれを個別に行っています（別のスレッドでサムネイルを要求します）-これのためのクエリAPIは不思議に思うでしょう。基本的にはサムネイルをまとめてお願いします。そして、IAsyncEnumerableを取得できました。

繰り返しになりますが、MSはこのための単純なAPIを作成できます。今のところ、各ファイルに対して.GetThumbnailAsyncを実行するだけです。次に、APIを提供してください。そうすれば、後でAPIの速度を向上させることができます。

そのため、アプリが名前/パスまたは拡張子に基づいて対象のファイルを検索する必要がある場合は、* FromApp APIを使用して検索できます。次に、名前に基づいてStorageFileを作成し、詳細を取得します。その中には重複したオーバーヘッドがありますが、この場合はアクセスチェックが2回実行されるためです。

プラス面として、* FromApp APIには、作成時間、最終アクセス時間、最終書き込み時間、ファイルサイズなどの多くの情報がすでに存在します。

1つのファイルだけを見つけようとしている場合、それは多くの場合問題ではありませんが、大規模な冗長性にはコストがかかる可能性があります。 Windows.Storage.Search.IndexerOption.OnlyUseIndexerAndOptimizeForIndexedPropertiesでStorageWinRT Apiを使用すると、非常に高速な列挙を取得できます。これは、オンデマンドで完全に実現されたストレージアイテムにフォールバックします。これは、パフォーマンスヒットがありますが、アイテムの作成よりも低くなります。追加のアクセスチェックを含める必要があるため、パスから。欠点は、ユーザーが問題の場所のインデクサーを無効にした場合は機能しないことです。

これにはいくつかの欠点があります。まず、私のテストでは、インデックスなしのファイルよりも高速でしたが、それほど高速ではありませんでした。 3倍から5倍速かったと思いますが、それでも* FromAppよりも約10倍から50倍遅くなります。それは非常に遅いです。その上、「ファイルのプロパティに加えてコンテキストにインデックスを付けるすべてのファイル」をチェックするようにユーザーに指示することはできません。それは単に彼のオプションです。そして、おそらく多くのユーザーは単にそれをチェックしないままにしておきます。

実際、Windowsは使用済みファイルを自動的に把握し、それらのフォルダーにインデックスを付ける必要があります。メディアファイル（ビデオ/写真/音楽）やドキュメントにとっては非常に重要になる可能性があります。

写真/メディアタイプのアプリのようにUIにデータを入力する場合は、仮想化などのUIでの使用シナリオを対象としているため、BulkAccessクラスがおそらく最善の策です。これにより、UIにデータをすばやく提供し、より多くのデータをフィードできます。ユーザーがコンテンツをスクロールするときに、必要に応じて。

正直なところ、私はこれが存在することにさえ気づいていませんでした-私たちが話しているときに私はそれを見ています。
ただし、これを正しく理解していれば、IStorageQueryと同じパフォーマンスの問題が発生するため、これはほんの少しの構文糖衣です。

そして、それらのパフォーマンスの問題は非常に大きなものです。それらは非常に巨大であるため、基本的に、約1000ファイルの場合、最初のファイルは9〜10秒後に取得されます。つまり、結果の列挙を開始すると、何もする前に9〜10秒間ブロックされます。同じことがFileInformationFactoryを使用していると思いますが、その間UIが応答するだけです。

WinRTは大きな表面であり、MSの単一のチームによって所有されていません。各チームはリリースごとに優先順位を評価し、事前に計画を公開する場合としない場合があります。個人的には、アプリコンテナの内外でWin32APIに関してゼロオーバーヘッドが発生する場所に到達することを望んでいます。

ええと、私たちの多くも;）WinRTはWindowsの大きな部分であり、さまざまな部分がさまざまなチームに散在していることを理解しています。

MSがWinRTに対して持っているビジョンを公に見ないことは、私たちにとってあまり快適ではありません。何が起こるか/いつ/起こるかについてのタイムラインを持たないこと。

私にとって、ファイル/フォルダの処理速度は単に最優先事項です。フォルダ内のファイルを列挙するのに非常に時間がかかる可能性があるような単純なことを行う場合、誰かがWinRT / UWPをどのように信頼できますか？そして、それを改善する方法を見つけることは、「グーグル検索が* FromAppAPIにぶつかるのに十分幸運でしょうか」ということになりますか？

私は恩知らずに出くわしたくありません-時間を割いて、これらすべてを私たちに概説してくれて本当に感謝しています。ありがとうございました！

jtorjo 2020年04月03日

@BenJKuhn誰か（https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html?childToView=25297#comment-25297）がTheに関する別のチケットを提出しましたここで「新しい証明書」の問題-> https://aka.ms/AA8bw9v

本当に悪い面ですが、これにアクセスしようとしましたが、このチケットを表示するためのアクセス権がないことがわかりました。これは、「フィードバックハブ」の信頼性にはまったく役立ちません。

jtorjo 2020年05月05日

なぜMSストアの外部でサイドローディングを許可するのに、実際にそれを実行することをほぼ不可能にするのですか？

実際、それは真実ではありません。アプリケーションをMSStoreにアップロードして、アプリをインストールする別の方法としてappinstallerを使用することはできません。私のアプリは、認証中にそのために禁止されました。
MSストアポリシー：
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

10.1.5
アプリは、Microsoftストアを通じてのみソフトウェアを宣伝または配布する場合があります。

サーバーからappinstallerファイルを削除する必要があった後、ユーザーはMSStoreを再度使用してアプリをインストールできます。私は理解しています-ルールはルールです、私でさえそれらの理由を得ることができません。しかし、ストアとappinstaller（Unigram）またはchocolatey（新しいMSターミナル）を介して配布される多くのアプリケーションを知っていると、本当に残念です。

maxkatz6 2020年05月06日

なぜMSストアの外部でサイドローディングを許可するのに、実際にそれを実行することをほぼ不可能にするのですか？
実際、それは真実ではありません。アプリケーションをMSStoreにアップロードして、アプリをインストールする別の方法としてappinstallerを使用することはできません。私のアプリは、認証中にそのために禁止されました。
MSストアポリシー：
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

ここで同じことを話しているかどうかはわかりません。この時代では、MSStoreが必要または必要な理由を1つだけ思いつくことはできません。それを使った私の牛肉は、アプリを開発してMSストアの外に展開するのがめちゃくちゃ難しいことでした。

jtorjo 2020年05月06日

Microsoft-ui-xaml: ディスカッション：WinRTに価値を付加する機会

ディスカッション：WinRTに価値を付加する機会

ファイルAPIのクエリが遅い

BroadSystemAccess API

MSストアの外部でサイドローディングするためのアプリを作成する

「新しい証明書」の問題

相互運用性：ゼロ

最も参考になるコメント

WinRT vs. UWP vs. .NET –いくつかの背景

特定のAPIに関するフィードバック

最新のアプリのファイルシステムAPIは、痛々しく、予想外に遅い

BroadSystemAccess API /機能は、実装されているため実用的ではありません。

MSストアの外部でサイドローディングするためのアプリを作成する

新しい証明書の発行とプライベート配布

WinRT型システムは、優れたAPIとライブラリを提供する機能に影響を与えます

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプ​​トを表示する必要があります

非同期APIはまだ手に負えないので、非同期であってはならないものには扱いにくいようです

WinRTには優れたオーディオAPIはありません

クリップボードの痛み

まとめ

全てのコメント108件

ノキアの壊滅的な過ちの繰り返し

重大な変更

マネージコードの見方の逆転

列付きリストGUIの重要性

C ++ / CXは最近C ++ / WinRTに置き換えられました

UWPファイルシステムはまだアルファ版です

ここで率直に言ってみましょう-些細なことではないアプリは、真空の中には存在しません。

WinRT vs. UWP vs. .NET –いくつかの背景

特定のAPIに関するフィードバック

最新のアプリのファイルシステムAPIは、痛々しく、予想外に遅い

BroadSystemAccess API /機能は、実装されているため実用的ではありません。

MSストアの外部でサイドローディングするためのアプリを作成する

新しい証明書の発行とプライベート配布

WinRT型システムは、優れたAPIとライブラリを提供する機能に影響を与えます

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプ​​トを表示する必要があります

非同期APIはまだ手に負えないので、非同期であってはならないものには扱いにくいようです

WinRTには優れたオーディオAPIはありません

クリップボードの痛み

まとめ

WinRT vs. UWP vs. .NET –いくつかの背景

最新のアプリのファイルシステムAPIは、痛々しく、予想外に遅い

BroadSystemAccess API /機能は、実装されているため実用的ではありません。

MSストアの外部でサイドローディングするためのアプリを作成する

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプ​​トを表示する必要があります

非同期APIはまだ手に負えないので、非同期であってはならないものには扱いにくいようです

WinRTには優れたオーディオAPIはありません

クリップボードの痛み

これが私が作成したフィードバックハブの問題です

私が作成した他のもの

よくわからないこと

フィードバックハブ

関連する問題

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプトを表示する必要があります

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプトを表示する必要があります

フィードバックHubは、コンテンツが誤って削除されるのを防ぐために、放棄するときにプロンプトを表示する必要があります