Power Apps の App オブジェクト
適用先: キャンバス アプリ モデル駆動型アプリ
現在実行中のアプリとアプリの動作に対する制御に関する情報を提供します。
内容
コントロールのように、App オブジェクトは、表示されている画面を識別し、変更が失われないように保存するようユーザーに促すプロパティを提供します。 すべてのアプリには App オブジェクトがあります。
App オブジェクトの一部のプロパティには、式を記述することができます。 ツリー ビュー ウィンドウの一番上で、その他のコントロールまたは画面と同じように App オブジェクトを選択します。 数式バーの左側にあるドロップダウン リストでオブジェクトのプロパティの 1 つを選択して、表示および編集を行います。
ActiveScreen プロパティ
ActiveScreen プロパティは、表示されている画面を識別します。
このプロパティは画面オブジェクトを返します。 数式 App.ActiveScreen.Name 付きの名前など、現在表示されている画面のプロパティを参照するために使用します。 App.ActiveScreen = Screen2 比較式などを使用して、このプロパティを別の画面オブジェクトと比較し、Screen2 が現在表示されている画面かどうかをテストすることもできます。
Back または Navigate 関数を使用して、表示されている画面を変更します。
BackEnabled プロパティ
BackEnabled プロパティは、Power Apps Mobile で実行している場合デバイスの戻るジェスチャに対するアプリの応答方法を変更します (Android デバイスでスワイプまたはハードウェアの戻るボタンを使用し、iOS デバイスで左から上にスワイプします)。 有効にすると、デバイスの戻るジェスチャは戻る式と同様に、最後に表示された画面に戻ります。 無効にすると、デバイスの戻るジェスチャによってユーザーはアプリ リストに戻ります。
ConfirmExit プロパティ
保存されていない変更を失いたい人はいません。 ConfirmExit および ConfirmExitMessage プロパティを使用し、アプリを閉じる前にユーザーに警告します。
Note
- たとえば、Power BI および SharePoint など、埋め込まれたアプリで ConfirmExit は動作しません。
- 遅延した読み込みのプレビュー機能が有効になっている場合 (新しいアプリでは既定)、これらのプロパティは最初の画面上のコントロールを参照できます。 参照が作成される場合、Power Apps Studio はエラーを表示しませんが、結果として公開されるアプリは Power Apps モバイルまたはブラウザーでは開きません。 この制限の解消に積極的に取り組んでいます。 その間、設定>今後の機能 (プレビュー 下の) にある 遅延負荷 をオフにすることができます。
ConfirmExit
ConfirmExit は、true の場合、アプリを閉じる前に確認ダイアログ ボックスを開く、ブール値のプロパティです。 既定では、このプロパティは false で、ダイアログ ボックスは表示されません。
ユーザーがアプリに変更を保存していない可能性がある状況では、このプロパティを使用して、アプリを終了する前に確認ダイアログ ボックスを表示します。 変数およびコントロールのプロパティを確認する式を使用します (Edit form コントロールの Unsaved プロパティなど)。
次の例のように、データが失われる可能性がある状況では、確認ダイアログ ボックスが表示されます。
- Exit 関数を実行しています。
- アプリがブラウザーで実行されている場合:
- アプリが実行されているブラウザーまたはブラウザー タブを閉じます。
- ブラウザーの戻るボタンを選択します。
- Self の LaunchTarget で Launch 関数を実行します。
- アプリが Power Apps Mobile (iOS または Android) で実行されている場合:
- スワイプすることで、Power Apps モバイルの異なるアプリに切り替えます。
- Android デバイス上の戻るボタンを選択します。
- Launch 関数を実行して、別のキャンバス アプリを起動します。
確認ダイアログ ボックスの正確な外観は、Power Apps のデバイスおよびバージョン間でさまざまです。
確認ダイアログ ボックスは、Power Apps Studio では表示されません。
ConfirmExitMessage
既定では、確認ダイアログ ボックスに変更が保存されていない可能性があります。などの、汎用メッセージがユーザーの言語で表示されます。
ConfirmExitMessage を使用し、確認ダイアログ ボックスのカスタム メッセージを指定します。 このプロパティが空白の場合、既定値が使用されます。 カスタム メッセージは確認ダイアログ ボックスに合わせて必要に応じて切り詰められるため、メッセージは最大で数行にします。
ブラウザー内で、確認ダイアログ ボックスにブラウザーからの汎用メッセージが表示されることがあります。
Note
App オブジェクトにはさらに実験的な OnMessage
と BackEnabled
の 2 つのプロパティがあります。 これらのプロパティは、最終的にアプリ オブジェクトから削除されます。 これらのプロパティを運用環境で使用しないことをお勧めします。
例
AccountForm および ContactForm の、2 つのフォーム コントロールを含むアプリを作成します。
App オブジェクトの ConfirmExit プロパティをこの式に設定します。
AccountForm.Unsaved Or ContactForm.Unsaved
このダイアログボックスは、ユーザーがいずれかのフォームでデータを変更し、変更を保存せずにアプリを閉じようとした場合に表示されます。
App オブジェクトの ConfirmExitMessage プロパティをこの数式に設定します。
If( AccountsForm.Unsaved, "Accounts form has unsaved changes.", "Contacts form has unsaved changes." )
このダイアログボックスは、ユーザーが取引先企業フォームでデータを変更し、変更を保存せずにアプリを閉じようとした場合に表示されます。
Application Insights 用計測キーの設定
システム生成アプリケーション ログをApplication Insights にエクスポートするには、キャンバス アプリのインストルメンテーション キーを設定する必要があります。
- Power Apps Studio で編集のためにアプリを開きます。
- 左側のナビゲーションのツリー ビューでアプリ オブジェクトを選択します。
- プロパティ ペインでインストルメンテーション キーを入力します。
データが App Insights に送信されない場合は、Power Platform 管理者に問い合わせて、App Insights がテナント レベルで無効になっているかを確認してください。
Formulas プロパティ
Formulas プロパティで名前付き計算式を使用して、アプリ全体で再利用できる式を定義します。
Power Apps では、数式がコントロール プロパティの値を決定します。 たとえば、アプリ全体で一貫した背景色を設定するには、それぞれのFillプロパティを一般的な数式に設定できます。
Label1.Fill: ColorValue( Param( "BackgroundColor" ) )
Label2.Fill: ColorValue( Param( "BackgroundColor" ) )
Label3.Fill: ColorValue( Param( "BackgroundColor" ) )
この数式が表示される場所が非常に多いため、変更が必要な場合にそれらすべてを更新するのは面倒で、エラーが発生しやすくなります。 代わりに、OnStart でグローバル変数を作成して、色を一度設定してから、アプリ全体で値を再利用します。
App.OnStart: Set( BGColor, ColorValue( Param( "BackgroundColor" ) ) )
Label1.Fill: BGColor
Label2.Fill: BGColor
Label3.Fill: BGColor
この方法のほうが優れていますが、BGColor の値が設定される前の OnStart の実行に依存しています。 BGColor はまた、作成者が気付いていないアプリの一部で操作されたり、他の誰かによって行われた変更であったり、追跡が困難な場合があります。
名前付き計算式によって代替手段が提供されます。 通常制御プロパティ = 式を書いているように、代わりに名前 = 式を書くことができ、名前をアプリ全体で再利用して表現を置き換えることができます。 これらの数式の定義は、Formulas プロパティで行われます。
App.Formulas: BGColor = ColorValue( Param( "BackgroundColor" ) );
Label1.Fill: BGColor
Label2.Fill: BGColor
Label3.Fill: BGColor
名前付き計算式を使用する利点は次のとおりです。
- 数式の値は常に利用可能です。 タイミング依存関係も、値が設定される前に最初に実行する必要のある OnStart もなく、式の値が不正確になる時間もありません。 名前付き計算式は、循環参照を作成しない限り、任意の順序で相互に参照できます。 それらは並行して計算できます。
- 数式の値は常に最新です。 数式は、コントロール プロパティまたはデータベース レコードに依存する計算を実行でき、それらが変更されると、数式の値が自動的に更新されます。 変数の場合のように値を手動で更新する必要はありません。 また、数式は必要な場合にのみ再計算されます。
- 式の定義は不変です。 数式の定義は信頼できる唯一の情報源であり、アプリ内の他の場所で値を変更することはできません。 変数では、あるコードが予期せず値を変更してしまう可能性がありますが、名前付き数式ではこのようなデバッグしにくい状況はありえません。
- 数式の計算は延期できます。 値が不変であるため、必要なときにいつでも計算できます。つまり、必要になるまでは計算する必要がありません。 アプリのスクリーン 2 まで使用されない数式の値はスクリーン 2 が表示されるまで計算する必要はないと表示されます。 この作業を遅延させることにより、アプリの読み込み時間を改善できます。 名前付き計算式は宣言型であり、システムが計算方法とタイミングを最適化する機会を提供します。
- 名前付き計算式は Excel の概念です。 非常に多くの人が Excel をよく知っているので Power Fx は可能な限り Excel の概念を使用します。 名前付き計算式は、名前マネージャーで管理される Excel の名前付きセルおよび名前付き計算式と同等です。 スプレッドシートのセルやコントロール プロパティのように、自動的に再計算されます。
名前付き計算式は、Formulas プロパティで順番に定義され、それぞれセミコロンで終わります。 数式の型は、数式内の要素の型と、それらがどのように一緒に使用されるかから推測されます。 たとえば、これらの名前付き計算式は、現在のユーザーに関する有用な情報を Dataverse から取得します。
UserEmail = User().Email;
UserInfo = LookUp( Users, 'Primary Email' = User().Email );
UserTitle = UserInfo.Title;
UserPhone = Switch( UserInfo.'Preferred Phone',
'Preferred Phone (Users)'.'Mobile Phone', UserInfo.'Mobile Phone',
UserInfo.'Main Phone' );
UserTitle の式を更新する必要がある場合、この 1 つの場所で簡単に行うことができます。 もしも UserPhone アプリでは必要ない場合、これらの Dataverse のユーザー テーブルへの呼び出しは作られません。 使用されていない数式定義を含めても問題はありません。
名前付き計算式のいくつかの制限:
- 動作関数を使用したり、アプリ内で副作用を引き起こしたりすることはできません。
- 循環参照を作成することはできません。 a = b; と b = a; を同じアプリ内で持つことは許可されていません。
ユーザー定義関数
重要
- ユーザー定義関数は実験段階です。
- 実験的な機能は本番用ではなく、完全ではない可能性があります。 これらの機能は公式リリースの前に使用できるため、一足先にアクセスして フィードバックを送る ことができます。 詳細: キャンバス アプリで実験的、プレビューおよび廃止された機能を理解する
- この記事で説明されている動作は、設定 > 今後リリースの機能 > 実験的 のユーザー定義関数の実験的機能がオンになっている場合にのみ利用可能です (既定ではオフになっています)。
- お客様のフィードバックは弊社にとって重要です。 ご意見やフィードバックにつきましては、Power Apps 実験的機能のコミュニティ フォーラム にお寄せください。
Power Fx には、If、Text、Set などの組み込み関数の長いリストがあります。 ユーザー定義関数を使用すると、組み込み関数と同様に、パラメーターを受け取って値を返す独自の関数を記述できます。 ユーザー定義関数は、パラメーターを追加し、動作の数式をサポートする名前付き数式の拡張機能と考えることができます。
たとえば、ライブラリからフィクションの本を返す名前付き数式を定義できます。
Library = [ { Title: "The Hobbit", Author: "J. R. R. Tolkien", Genre: "Fiction" },
{ Title: "Oxford English Dictionary", Author: "Oxford University", Genre: "Reference" } ];
LibraryFiction = Filter( Library, Genre = "Fiction" );
パラメーターがない場合は、ジャンルごとに個別の名前付き数式を定義する必要があります。 代わりに、名前付き数式をパラメーター化しましょう。
LibraryType := Type( [ { Title: Text, Author: Text, Genre: Text } ] );
LibraryGenre( SelectedGenre: Text ): LibraryType = Filter( Library, Genre = SelectedGenre );
ユーザー定義関数ひとつつで LibraryGenre( "Fiction" )
、LibraryGenre( "Reference" )
を呼び出したり、他のジャンルのフィルターをかけたりできるようになりました。
構文は次のとおりです。
FunctionName( [ ParameterName1: ParameterType1 [ , ParameterName2: ParameterType2 ... ] ] ) : ReturnType = Formula;
- FunctionName – 必須です。 ユーザー定義関数の名前です。
- ParameterName(s) – 省略可能。 関数パラメーターの名前。
- ParameterType(s) – 任意です。 組み込みデータ型名、データ ソース名、または Type 関数で定義された型の名前です。
- ReturnType – 必須です。 関数からの戻り値の型。
- Formula – 必須。 パラメーターに基づいて関数の値を計算する数式。
各パラメーターとユーザー定義関数からの出力は、型を指定する必要があります。 この例では、SelectedGenre: Text
は関数の最初のパラメーターを Text 型に定義し、SelectedGenre
はフィルター操作のボディで使用されるパラメーターの名前です。 サポートされている型名についてはデータ型を参照してください。
Type 関数は、ライブラリの集約型を作成するために使用され、関数から書籍のテーブルを返すことができます。
LibraryType
をレコード型の複数のテーブルと定義しました。 ひとつのブックを関数に渡す場合、RecordOf関数でこのテーブルのレコードの型を抽出することができます:
BookType := Type( RecordOf( LibraryType ) );
IsGenre( Book: BookType, SelectedGenre: Text ): Boolean = (Book.Genre = SelectedGenre);
関数パラメーターのレコード マッチングは、Power Fx の他の部分よりも厳しくなっています。 レコード値のフィールドは、型定義の適切なサブセットである必要があり、追加のフィールドを含めることはできません。 たとえば IsGenre( { Title: "My Book", Published: 2001 }, "Fiction" )
はエラーになります。
再帰はユーザー定義関数ではまだサポートされていないことに注意してください。
ユーザー定義関数の動作
名前付き数式とほとんどのユーザー定義関数は、Set や Notify のような副作用を持つ行動関数をサポートしていません。 その代わりに関数型プログラミングのパターンに頼り、必要に応じて Power Fx が自動的に計算式を再計算するようにするのが最良です。 しかし、やむを得ない場合もあります。 ユーザー定義関数に動作ロジックを含めるには、本文を中かっこで囲みます。
Spend( Amount: Number ) : Void = {
If( Amount > Savings,
Error( $"{Amount} is more than available savings" ),
Set( Savings, Savings - Amount );
Set( Spent, Spent + Amount)
);
}
これで Spend( 12 )
を呼び出して、Savings に 12 があるかどうかをチェックし、もしあれば 12 を引いて、Spent 変数に 12 を加えます。 この関数は値を返さないため、戻り値の型は Void です。
動作ユーザー定義関数の構文は次のとおりです。
FunctionName( [ ParameterName1: ParameterType1 [ , ParameterName2: ParameterType2 ... ] ] ) : ReturnType = { Formula1 [ ; Formula2 ... ] };
- FunctionName – 必須です。 ユーザー定義関数の名前です。
- ParameterName(s) – 省略可能。 関数パラメーターの名前。
- ParameterType(s) – 任意です。 組み込みデータ型名、データ ソース名、または Type 関数で定義された型の名前です。
- ReturnType – 必須です。 関数からの戻り値の型。 関数が値を返さない場合は Void を使用します。
- Formula(s) - 必須。 パラメーターに基づいて関数の値を計算する数式。
すべての Power Fx 数式と同様に、エラーが発生しても実行は終了しません。 Error 関数が呼び出された後、If 関数が Savings と Spent の変更を防ぎます。 IfError 関数は、エラー後の実行を阻止する目的でも使用できます。 Void を返しても、問題があれば数式はエラーを返します。
ユーザー定義の型
重要
- ユーザー定義の型は実験的な機能です。
- 実験的な機能は本番用ではなく、完全ではない可能性があります。 これらの機能は公式リリースの前に使用できるため、一足先にアクセスして フィードバックを送る ことができます。 詳細: キャンバス アプリで実験的、プレビューおよび廃止された機能を理解する
- この記事で説明されている動作は、設定 > 今後リリースの機能 > 実験的 のユーザー定義の型の実験的機能がオンになっている場合にのみ利用可能です (既定ではオフになっています)。
- お客様のフィードバックは弊社にとって重要です。 ご意見やフィードバックにつきましては、Power Apps 実験的機能のコミュニティ フォーラム にお寄せください。
名前付き数式は、ユーザー定義の型を作成するために Type 関数と一緒に使用することができます。 ユーザー定義の型を定義する場合は、=
の代わりに :=
を使用します (Book := Type( { Title: Text, Author: Text } )
など)。 詳細と例については、Type関数を参照してください。
OnError プロパティ
OnError を使用して、アプリのどこかでエラーが発生したときにアクションを実行します。 エンドユーザーに表示される前にエラー バナーをインターセプトするグローバルな機会となります。 また、Trace 関数 でエラーを記録したり、データベースや Web サービスに書き込んだりすることも可能です。
Canvas アプリでは、数式の評価結果がすべてエラー チェックされます。 エラーが発生した場合、OnError は、式全体が IfError 関数でラップされていた場合と同じ FirstError と AllErrors スコープ変数で評価されます。
OnError が空の場合、既定のエラー バナーで、エラーの FirstError.Message が表示されます。 OnError 式を定義すると、この動作が上書きされ、作成者が適切と考えるエラー報告を処理することができます。 OnError で既定の動作を要求し、Error 関数 でエラーを再投入できます。 あるエラーはフィルターにかけたり、別の方法で処理し、他のエラーはスルーする場合は、rethrowing アプローチを使用します。
OnError は、IfError のように計算の誤りを置き換えることはできません。 OnError が呼び出された場合、エラーはすでに発生しており、IfError などの数式計算によって処理されています。OnError はエラー報告のみを制御します。
OnError 式は同時に評価され、その評価が他のエラーの処理と重なる可能性があります。 たとえば、OnError の先頭でグローバル変数を設定し、後から同じ数式で読み込むと、値が変わっていることがあります。 With 関数 を使用して、数式にローカルな名前付き値を作成します。
各エラーは OnError によって個別に処理されますが、既定のエラー バナーは各エラーに対して個別に表示されない場合があります。 同時に多くのエラーバナーが表示されることを避けるため、同じエラーバナーが最近表示された場合は、再度表示されません。
例
式で結合された Label コントロールと Slider コントロールを考えてみましょう:
Label1.Text = 1/Slider1.Value
スライダーの既定値は 50 です。 スライダーを 0 にすると、Label1 の値は表示されず、エラー バナーが表示されます。
何が起こったのかを詳しく見てみましょう:
- ユーザーがスライドを左に移動し、 Slide1.Value プロパティが 0 に変更されました。
- Label1.Text が自動的に再評価されました。 ゼロ除算が発生し、エラーが発生しました。
- この式では IfError はありません。 ゼロ除算エラーは、数式評価によって返されます。
- Label1.Text はこのエラーに対して何も表示できないので、空白の状態が表示されます。
- OnError が呼び出されます。 ハンドラーがないため、標準エラー バナーがエラー情報とともに表示されます。
必要に応じて、計算式を Label1.Text = IfError( 1/Slider1.Value, 0 )
に修正することも可能です。
IfError を使用すると、エラーもエラーバナーも表示されません。 その時点ですでにエラーは発生しているため、OnError からエラーの値を変更することはできず、どのように報告するかという問題にすぎません。
OnError ハンドラを追加しても、ステップ 5 以前には何の影響もありませんが、エラーの報告方法には影響します:
Trace( $"Error {FirstError.Message} in {FirstError.Source}" )
この OnError ハンドラを配置することで、アプリのユーザーから見れば、エラーは発生しません。 しかし、エラーは、FirstError からのエラー情報のソースとともに、監視のトレースに追加されます:
トレースに加えて、同じ既定のエラー バナーも表示させる場合は、Trace がなかった場合と同じように、Trace 呼び出し後に Error 関数でエラーを再スローすることが可能です。
Trace( $"Error {FirstError.Message} in {FirstError.Source}" );
Error( FirstError )
OnStart プロパティ
Note
OnStart プロパティを使用すると、アプリの読み込み時にパフォーマンスの問題を引き起こすことがあります。 プロパティを使用する上位 2 つの理由データのキャッシュとグローバル変数の設定については、代替案を作成中です。 Navigate で表示される最初の画面を定義するための代替案をすでに作成しました。 コンテキストによっては、このプロパティは既定で無効になっている場合があります。 表示されておらず、使用する必要がある場合は、スイッチを有効にするためにアプリの詳細設定を確認してください。 画面の OnVisible プロパティも使用できます。 既定では、ノン ブロッキングの OnStart ルールを有効にすると、OnStart 関数が他のアプリ ルールと同時に実行されるようになります。 そのため、他のアプリのルールで参照されている変数が OnStart 関数内で初期化されている場合、それらはまだ完全に初期化されていない可能性があります。 さらに、これらの関数の実行が長時間かかる場合、特に、Screen.OnVisible または App.OnStart 関数の実行が完了する前に、画面がレンダリングされてインタラクティブになる可能性があります。
OnStart プロパティは、ユーザーがアプリを開始するときに実行されます。 このプロパティは、次のタスクを実行するためによく使用されます:
この数式は最初の画面が表示される前に評価されます。 画面が読み込まれないため、UpdateContext 関数を使用してコンテキスト変数を設定することはできません。 ただし、Navigate 関数を使用してコンテキスト変数を渡すことはできます。
OnStart プロパティを変更した後、ツリー ビュー ペインで アプリ オブジェクトにカーソルを合わせて、省略記号 (...) を選択し、OnStart を実行 を選択してテストします。 アプリが初めて読み込まれるときとは異なり、既存のコレクションおよび変数はすでに設定されています。 空のコレクションから始めるには、Collect 関数の代わりに、ClearCollect 関数を使用します。
注意
- OnStart プロパティでの Navigate 関数の使用は廃止されました。 既存のアプリは引き続き機能します。 期間限定で、アプリの設定で有効にすることができます (廃止 で使用可能)。 ただし、この方法で Navigate を使用すると、最初の画面を表示する前にシステムが OnStart の評価を完了しなければならないため、アプリの読み込みが遅れる可能性があります。 代わりに、StartScreen プロパティを使用して、最初に表示される画面を計算します。
- 2021 年 3 月以前に作成されたアプリで、2021 年 3 月から現在までの間に OnStart にNavigate を追加した場合、廃止したスイッチはオフになります。 このようなアプリを Power Apps Studio で編集すると、エラーが表示される場合があります。 このエラーをクリアするには、廃止されたスイッチをオンにします。
StartScreen プロパティ
StartScreen プロパティは、最初に表示される画面を決定します。 アプリが読み込まれるときに一度評価され、表示される画面オブジェクトを返します。 既定では、このプロパティは空で、スタジオ ツリー ビューの最初の画面が最初に表示されます。
StartScreen は、動作関数を含めることができないデータ フロー プロパティです。 すべてのデータ フロー関数が使用可能で、特に、次の関数と信号を使用して、最初に表示する画面を決定します:
- アプリの起動に使用されるパラメーターを読み取る Param 関数。
- 現在のユーザーに関する情報を読み取る User 関数。
- LookUp、Filter、CountRows、Max など、データ ソースから読み取る関数。
- API はコネクタで呼び出しますが、すぐに戻ることに注意してください。
- Connection、Compass、App などの信号。
Note
OnStart で作成されたものを含むグローバル変数とコレクションは StartScreen で使用できません。 名前付き数式が使用可能であり、多くの場合、アプリ全体で数式を再利用するための優れた代替手段です。
StartScreen がエラーを返すと、Studio ツリー ビューの最初の画面が、StartScreen が設定されていないかのように表示されます。 IfError 関数を使用してエラーを見つけ、適切なエラー画面にリダイレクトします。
Studio で StartScreen を変更した後、ツリー ビュー ペインで アプリ オブジェクトにカーソルを合わせて、省略記号 (...) を選択し、StartScreen に移動 を選択してテストします。 アプリが読み込まれたかのように画面が切り替わります。
使用例
Screen9
アプリが起動するたびに、Screen9
を最初に表示することを示します。
If( Param( "admin-mode" ) = 1, HomeScreen, AdminScreen )
Param "admin-mode" がユーザーによって設定されているかどうかを確認し、それを使用して HomeScreen または AdminScreen のどちらを先に表示するかを決定します。
If( LookUp( Attendees, User = User().Email ).Staff, StaffPortal, HomeScreen )
会議の参加者がスタッフ メンバーであるかどうかを確認し、起動時に適切な画面に移動します。
IfError( If( CustomConnector.APICall() = "Forest",
ForestScreen,
OceanScreen
),
ErrorScreen
)
API 呼び出しに基づいてアプリを ForestScreen
または OceanScreen
に移動します。 何らかの理由で API が失敗した場合、代わりに ErrorScreen
が使用されます。
StudioVersion プロパティ
StudioVersion プロパティを使って、アプリを公開するために使用された Power Apps Studio を表示または記録します。 これは、デバッグ時や、アプリが最新 Power Apps Studio バージョンで再公開されていることを確認する場合に役立ちます。
StudioVersion がテキストとして返されます。 テキストの形式は時間の経過とともに変化する可能性があるため、全体として扱う必要があります。個々の部分を抽出することは避けてください。