僕は、Power Appsを使って1000個のボタンが並ぶマトリックス画面を作成し、SharePointリストからデータを取得して各ボタンに表示するアプリを開発しました。最初は、ボタンに正しいデータが表示されず、選択結果がメイン画面に反映されないなど、予想外のトラブルに見舞われました。本記事では、最初の問題提起から、試行錯誤、失敗の数々、そして最終的な成功に至るまでの過程を詳しく紹介します。これから同様の課題に挑む方にとって、具体的な解決策と失敗事例を含めた実践レポートとして参考になれば幸いです。
背景と問題提起
当初の計画と誤認識
最初、僕は「1000個のボタンが横一列に並んでいるイメージ」でアプリを構築するつもりでした。しかし、Power Appsでは横方向のギャラリー内に縦方向のギャラリーを入れ子にして実装するため、実際にはボタンの並びはマトリックス形式となりました。さらに、内部で扱う連番の考え方についても誤解があり、データの整合性に問題が発生することに気づきませんでした。
挫折と試行錯誤の記録
開発初期、僕はCSV形式のデータをもとにSharePointリストに変換した「データリスト」を用いていました。このリストは、各行に連番情報があり、ボタンに表示すべき値が格納されているはずでした。しかし、実際にアプリを再生すると、各ボタンに値が全く表示されなかったのです。また、ボタンを押して選択結果を保持しようとしても、メイン画面へ遷移できず、何も反映されないという現象が続きました。最初はコードの書き方や変数の初期化に原因があるのではと考え、何度も設定を見直しましたが、問題はなかなか解決しませんでした。
振り返りと解決へのプロセス
データ構造の再確認
問題解決の鍵は、まず元データの構造にありました。僕が提供されたCSVのデータは、もともとある一定のパターン（たとえば「開始番号」「＋△」といった連番）で構成されていました。ところが、僕のアプリ内での連番計算では、誤って異なるパターン（例：「開始番号＋1」など）になっていたため、SharePointリスト上の行番号と一致しなかったのです。デバッグを重ねた結果、CSVの元データでは連番が【例：0、50、100、150…】のようになっていたにも関わらず、アプリ側の計算式が【例：1、51、101、151…】となっており、そこにズレがあったことが分かりました。
ギャラリー入れ子の実装と課題
Power Appsでマトリックス表示を実現するため、横方向のギャラリーに入れ子の縦方向ギャラリーを配置する構造を採用しました。横側のギャラリーでは各列番号（仮に「列番号」と呼ぶ）を生成し、縦側のギャラリーでは各行番号（「行番号」）を算出していました。しかし、行番号の計算式に誤りがあったため、SharePointリスト上の正しい行番号と一致せず、データの参照がうまくいかなくなっていました。
デバッグのポイントと失敗事例
僕はまず、マトリックス画面に一時的なラベルを配置して、変数「選択結果」に値が入っているか確認しました。すると、ボタンセルを押してテスト用に固定値をセットした場合は期待通り動作しました。しかし、本来のデータ取得コードに戻すと、SharePointリストからデータが取得できず、空白が返ってくるという結果に。
また、ボタンセルのOnSelectやTextプロパティにおいて、動的に列名を参照するためSwitch関数を用いた実装を試みたものの、元データと照合すると誤った連番計算が原因でデータが正しく参照されない事態が発生しました。最終的に、CSVの元データの行番号パターンに合わせるため、計算式を修正し、正しい行番号を設定することで解決に至りました。
最終的な実装方法と成功事例
アプリ全体の構成とコード概要
最終的なアプリは、メイン画面とマトリックス画面の2画面で構成されています。
メイン画面では、選択結果を表示するテキストボックスや、マトリックス画面への遷移ボタンが配置されています。
マトリックス画面では、横方向ギャラリー内に縦方向ギャラリーを入れ子にしたマトリックス表示を行い、各ボタンセルにはSharePointリストから参照した値が表示されます。
主な修正点
- 行番号の計算式修正
CSVの元データでは「開始番号」が【例：0、50、100、…】となっているため、ギャラリーの縦方向での計算式を【(値－1)×50】に修正しました。 - データ取得部分のコード変更
各ボタンセルのTextプロパティおよびOnSelectプロパティにおいて、Switch関数を用いて動的に列名を参照する実装を採用。
具体的には、SharePointリスト「マトリックスデータリスト」から、正しい行番号と列番号に対応するセルの値をLookUp関数で取得する形に変更しました。
成功に至る決定的な変更点
僕が最終的にたどり着いたのは、以下の2点です。
- 行番号計算の見直し
CSVデータの元構造とアプリ内計算の不一致が根本原因であったため、計算式を元データに合わせて修正。これにより、正しい行番号でデータが参照できるようになりました。 - データ取得コードの修正
ボタンセルのOnSelectおよびTextプロパティで、Switch関数を用いる実装から、元データの列名に合わせた形に統一。これにより、各ボタンに正しいデータが表示され、選択結果も正しく保持されるようになりました。
以下に、最終版の主要コード例を示します（固有名はすべて変更済み）。
App.OnStart
Set(選択結果, Blank())
メイン画面（メイン画面）
- 選択結果表示テキストボックスのDefaultプロパティ：
選択結果
- マトリックス画面遷移ボタンのOnSelectプロパティ：
Navigate(マトリックス画面, ScreenTransition.Fade)
マトリックス画面（マトリックス画面）
横ギャラリーのItemsプロパティ
ForAll(Sequence(50), {列番号: Value})
縦ギャラリーのItemsプロパティ
ForAll(
Sequence(100),
{
行番号: (Value - 1) * 50, // CSV元の連番に合わせた計算式
列番号: ThisItem.列番号,
セル番号: ThisItem.列番号 + (Value - 1) * 50
}
)
ボタンセル（各ボタン）のTextプロパティ
LookUp(
マトリックスデータリスト,
行番号 = ThisItem.行番号,
Switch(
ThisItem.列番号,
1, "列１",
2, "列２",
3, "列３",
/* … 略 … */
50, "列50",
""
)
)
ボタンセルのOnSelectプロパティ
Set(
選択結果,
LookUp(
マトリックスデータリスト,
行番号 = ThisItem.行番号,
Switch(
ThisItem.列番号,
1, "列１",
2, "列２",
3, "列３",
/* … 略 … */
50, "列50",
""
)
)
)
選択ボタンのOnSelectプロパティ
If(
!IsBlank(選択結果),
Navigate(メイン画面, ScreenTransition.None)
)
この最終版コードにより、各ボタンにSharePointリストから正しい値が表示され、ボタン押下によって選択結果が保持され、選択ボタンでメイン画面に遷移する動作が実現できました。
おわりに
今回、僕はPower Appsのギャラリー入れ子構造を活用し、SharePointリストからデータを取得するという複雑な課題に直面しました。最初は数多くの失敗と混乱がありましたが、データの元構造とアプリ内計算式の不一致に気づき、計算式を元データに合わせて修正することで解決しました。この実践事例が、同様の問題に直面する方々の参考になれば幸いです。
技術的な壁にぶつかったときこそ、冷静に原因を見極め、一歩一歩修正していくことが大切だと実感しました。
コメント