MENU

.NET MAUIのSfPopup内でAvatarViewのコマンドが発火しない原因と解決策【x:DataTypeとBindingContextを徹底解説】

C#

.NET MAUI と Syncfusion SfPopup を組み合わせたとき、「AvatarView をタップしても RelayCommand が発火しない」「x:DataType と BindingContext の不一致警告が消えない」という相談はかなり多いです。本記事では、なぜこの現象が起きるのかを整理しつつ、実運用に耐える２つの実装パターン（パターンA/B）とデバッグの観点までまとめて解説します。

目次

.NET MAUI の SfPopup 内で AvatarView のコマンドが発火しない問題とは？

今回の前提となるシナリオは次のようなものです。

  • .NET MAUI アプリで Syncfusion の SfPopup を使用
  • ヘッダーに AvatarView（CommunityToolkit.Maui）を表示
  • ユーザーアイコンをタップしたら、[RelayCommand] で定義した AvatarImageClicked() を実行し、写真撮影／選択のアクションシートを開きたい
  • しかし実際には…
    • AvatarView をタップしても コマンドが発火しない
    • あるいは動いても XAML のコンパイルドバインディング警告が出る

特にややこしいのが次の状況です。

  • HeaderTemplate / ContentTemplate 側では x:DataType="model:LocalUser" を指定している
  • しかし実行時の BindingContext は AppShellViewModel のまま
  • 結果として「ImagePath は LocalUser にはあるが、今の BindingContext（AppShellViewModel）には存在しない」というコンパイルドバインディング警告が出る

この問題は、実は次の 2 点を押さえればスッキリ解消できます。

  • イベント → コマンドの接続方法
  • x:DataType と BindingContext の整合性

原因の整理：イベントと BindingContext の２つの落とし穴

よくある原因を表でまとめると、以下のようになります。

分類具体的な原因発生しがちな症状主な対処
イベント周りEventToCommandBehavior に EventName が指定されていない AvatarView 自体には Tapped イベントがないのに、それを前提に書いているタップしてもコマンドが発火しない ブレークポイントにも一切到達しないTapGestureRecognizer を使って Command を直接バインドする どうしても EventToCommandBehavior を使うなら EventName を明示
BindingContextテンプレートに x:DataType="model:LocalUser" を指定 しかし実行時の BindingContext は AppShellViewModel のままXAML コンパイル時に「プロパティが見つからない」警告 ランタイムでは動くが、補完やリファクタリングが効かないパターンA: x:DataType を VM に揃えて LocalUser.ImagePath のようにフルパスで書く パターンB: Popup の BindingContext を LocalUser に切り替え、コマンドだけ親 VM を参照する

解決策パターンA：Popup は ViewModel のまま、LocalUser をプロパティ経由で参照

最もシンプルで安全性が高いのが、このパターンAです。

  • Popup 全体（およびテンプレート）の BindingContext は AppShellViewModel のまま
  • x:DataType も vm:AppShellViewModel に揃える
  • LocalUser を VM のプロパティとして公開し、LocalUser.ImagePath のようにフルパスでバインドする
  • AvatarView のタップは TapGestureRecognizer.Command で直接コマンドをバインドする

AppShellViewModel の例

using CommunityToolkit.Mvvm.ComponentModel;
using CommunityToolkit.Mvvm.Input;

public partial class AppShellViewModel : ObservableObject
{
    [ObservableProperty]
    private LocalUser localUser;

    public AppShellViewModel()
    {
        LocalUser = new LocalUser
        {
            ImagePath = "avatar_default.png",
            Username = "FireChat User",
            StatusMessage = "Hello MAUI!"
        };
    }

    [RelayCommand]
    private async Task AvatarImageClicked()
    {
        // 写真の撮影/選択を表示する処理
        // ここでは例としてアクションシート
        var result = await Shell.Current.DisplayActionSheet(
            "プロフィール画像を変更",
            "キャンセル",
            null,
            "写真を撮影",
            "写真を選択");

        // result に応じた処理...
    }

    [RelayCommand]
    private void SavePopUpContent()
    {
        // LocalUser の変更内容を保存する処理
    }
}

SfPopup の XAML（パターンA）

<sfPopup:SfPopup
    x:Name="UserProfilePopup"
    AcceptButtonText="Save and close"
    AcceptCommand="{Binding SavePopUpContentCommand}">

    <sfPopup:SfPopup.HeaderTemplate>
        <DataTemplate x:DataType="vm:AppShellViewModel">
            <toolkit:AvatarView
                Margin="20,10,0,0"
                ImageSource="{Binding LocalUser.ImagePath}">
                <toolkit:AvatarView.GestureRecognizers>
                    <TapGestureRecognizer
                        Command="{Binding AvatarImageClickedCommand}" />
                </toolkit:AvatarView.GestureRecognizers>
            </toolkit:AvatarView>
        </DataTemplate>
    </sfPopup:SfPopup.HeaderTemplate>

    <sfPopup:SfPopup.ContentTemplate>
        <DataTemplate x:DataType="vm:AppShellViewModel">
            <Grid Padding="20" RowDefinitions="80,80" RowSpacing="5">
                <controls:MaterialEntry
                    Hint="Name"
                    Text="{Binding LocalUser.Username}" />

                <controls:MaterialEntry Grid.Row="1"
                    Hint="Status"
                    Text="{Binding LocalUser.StatusMessage}" />
            </Grid>
        </DataTemplate>
    </sfPopup:SfPopup.ContentTemplate>

</sfPopup:SfPopup>

パターンAのポイント

  • x:DataType と BindingContext を AppShellViewModel に統一しているため、コンパイルドバインディング警告が出ない
  • 編集対象のユーザー情報はすべて LocalUser 経由でアクセス
  • TapGestureRecognizer.Command によって、AvatarView のタップ → AvatarImageClickedCommand が確実に呼ばれる
  • EventToCommandBehavior を使わないため、イベント名の指定ミスなどの罠を回避できる

まずはこのパターンAを採用するのがおすすめです。Popup のスコープが「ログイン中のユーザーのプロフィール編集」程度であれば、この設計で十分シンプルかつ堅牢に動作します。

解決策パターンB：テンプレートを LocalUser ベースにし、コマンドだけ親 VM を参照

より「モデル中心」に書きたい場合は、テンプレート内の BindingContext を LocalUser に切り替え、コマンドだけ親の ViewModel を参照するパターンBが便利です。

  • Popup もしくはテンプレートの BindingContext を LocalUser に変更
  • x:DataType="model:LocalUser" と書けるため、バインディングパスが短くなる
  • Avatar をタップしたときのコマンドは、Shell や親ページの BindingContext から取得（x:Reference or RelativeSource）

Shell 側の定義例

<Shell
    x:Class="FireChat.AppShell"
    x:Name="RootShell"
    xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
    xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
    xmlns:sfPopup="clr-namespace:Syncfusion.Maui.Popup;assembly=Syncfusion.Maui.Popup"
    xmlns:toolkit="http://schemas.microsoft.com/dotnet/2022/maui/toolkit"
    xmlns:model="clr-namespace:FireChat.Models"
    xmlns:vm="clr-namespace:FireChat.ViewModels">

    <Shell.BindingContext>
        <vm:AppShellViewModel />
    </Shell.BindingContext>

    <sfPopup:SfPopup
        x:Name="UserProfilePopup"
        BindingContext="{Binding LocalUser}"
        AcceptButtonText="Save and close"
        AcceptCommand="{Binding Source={x:Reference RootShell},
                                Path=BindingContext.SavePopUpContentCommand}">

        <sfPopup:SfPopup.HeaderTemplate>
            <DataTemplate x:DataType="model:LocalUser">
                <toolkit:AvatarView ImageSource="{Binding ImagePath}">
                    <toolkit:AvatarView.GestureRecognizers>
                        <TapGestureRecognizer
                            Command="{Binding Source={x:Reference RootShell},
                                              Path=BindingContext.AvatarImageClickedCommand}" />
                    </toolkit:AvatarView.GestureRecognizers>
                </toolkit:AvatarView>
            </DataTemplate>
        </sfPopup:SfPopup.HeaderTemplate>

        <sfPopup:SfPopup.ContentTemplate>
            <DataTemplate x:DataType="model:LocalUser">
                <Grid Padding="20" RowDefinitions="80,80" RowSpacing="5">
                    <controls:MaterialEntry
                        Hint="Name"
                        Text="{Binding Username}" />

                    <controls:MaterialEntry Grid.Row="1"
                        Hint="Status"
                        Text="{Binding StatusMessage}" />
                </Grid>
            </DataTemplate>
        </sfPopup:SfPopup.ContentTemplate>
    </sfPopup:SfPopup>

</Shell>

パターンBのメリット・デメリット

観点メリットデメリット
バインディングパステンプレート内は ImagePath や Username だけで書けてシンプルコマンドだけ x:Reference RootShell などで親を参照する必要がある
設計の見通しテンプレートは完全に「LocalUser の見た目」として設計できる複数階層の親を参照する場合、XAML がやや複雑になりがち
再利用性LocalUser 専用テンプレートとして他の場所でも再利用しやすい親にコマンドが存在する前提があるため、切り離して使う場合は調整が必要

ビューの再利用性を重視したい場合や、「モデルごとに専用テンプレートを用意したい」ケースではパターンBが有力候補になります。

RelativeSource を使うバリエーション

x:Reference はわかりやすい反面、ルートに x:Name を必ず付ける必要があります。代わりに、RelativeSource で祖先要素（Shell やページ）の BindingContext をたどる方法もあります。

<TapGestureRecognizer
    Command="{Binding Source={RelativeSource AncestorType={x:Type Shell}},
                      Path=BindingContext.AvatarImageClickedCommand}" />

この書き方なら、ルート要素に名前を付けなくても、Shell（もしくはページ）に設定された ViewModel からコマンドを取得できます。アプリ全体の XAML をスッキリさせたい場合はこちらも検討できます。

RelayCommand と生成されるコマンド名の確認

MVVM Toolkit の [RelayCommand] を使うと、メソッドから自動的に *Command プロパティが生成されますが、ここでつまずくケースも多いです。

  • [RelayCommand] を付けたメソッド名：AvatarImageClicked
  • 生成されるプロパティ名：AvatarImageClickedCommand

そのため、XAML では必ず AvatarImageClickedCommand をバインドします。

<TapGestureRecognizer Command="{Binding AvatarImageClickedCommand}" />

また、MVVM Toolkit を使うときは次の点も要チェックです。

  • ViewModel クラスは partial にしているか
  • プロジェクトが一度ビルドされているか（ソースジェネレータが走る）
  • 名前空間の衝突（別のクラスにも同じ名前のメソッドやプロパティがないか）

これらが揃っていないと、XAML 上ではコマンド名が正しく補完されず、「存在しないプロパティをバインドしている」と誤解してしまうことがあります。

EventToCommandBehavior を使う場合の注意点

本記事では安定動作の観点から TapGestureRecognizer.Command を推奨していますが、既存コードで EventToCommandBehavior を使っている場合もあると思います。その場合の注意点は次の通りです。

  • EventName を必ず指定する
  • AvatarView 自体には Tapped イベントがないため、しばしば想定通り動かない
  • 素直に TapGestureRecognizer の Tapped に対して Behavior を付ける方が安全

例として、AvatarView に直接 EventToCommandBehavior を書くのではなく、TapGestureRecognizer に対して書く形です。

<toolkit:AvatarView ImageSource="{Binding LocalUser.ImagePath}">
    <toolkit:AvatarView.GestureRecognizers>
        <TapGestureRecognizer>
            <TapGestureRecognizer.Behaviors>
                <behaviors:EventToCommandBehavior
                    EventName="Tapped"
                    Command="{Binding AvatarImageClickedCommand}" />
            </TapGestureRecognizer.Behaviors>
        </TapGestureRecognizer>
    </toolkit:AvatarView.GestureRecognizers>
</toolkit:AvatarView>

ただしここまでして EventToCommandBehavior を使うメリットは薄いので、可能であればシンプルに TapGestureRecognizer.Command に置き換えてしまうのがおすすめです。

x:DataType と BindingContext を正しく揃えるための設計指針

x:DataType は コンパイル時の型チェックとインテリセンスのための情報であり、実行時の BindingContext を変更するものではありません。ここを誤解すると警告の嵐になります。

設計時の指針として、次のどちらかに必ず寄せると混乱が小さくなります。

  • パターンA型：テンプレートの x:DataType を ViewModel に合わせる
    • BindingContext = AppShellViewModel
    • x:DataType="vm:AppShellViewModel"
    • モデルは LocalUser.ImagePath のようにフルパスで参照
  • パターンB型：テンプレートの BindingContext をモデルに切り替える
    • BindingContext = LocalUser
    • x:DataType="model:LocalUser"
    • ただしコマンドなど、ViewModel の責務は元の VM を x:Reference で参照

どちらかに統一してしまえば、「この XAML では何が BindingContext なのか？」で迷うことが大幅に減り、MVVM 全体の見通しも良くなります。

デバッグ時のチェックリスト

「AvatarView をタップしても何も起きない」「警告が消えない」といった状況にハマったときは、次のチェックリストを順番に確認してみてください。

  • 1. TapGestureRecognizer が付いているか？
    • AvatarView に GestureRecognizers が定義されているか
    • そこに TapGestureRecognizer が存在するか
    • 別の要素がタップイベントを奪っていないか（透明なボタンなど）
  • 2. Command のパスは正しいか？
    • AvatarImageClicked ではなく AvatarImageClickedCommand をバインドしているか
    • スペルミスや大文字・小文字の違いがないか
  • 3. BindingContext は想定どおりか？
    • デバッグ実行時にブレークポイントで this.BindingContext をウォッチする
    • SfPopup の表示タイミングで BindingContext が別インスタンスに差し替わっていないか
  • 4. x:DataType の警告内容を読んだか？
    • 「型 X にプロパティ Y は存在しません」という警告になっていないか
    • 一時的に x:DataType="{x:Null}" にして警告が消えるか確認する
  • 5. RelayCommand のソースジェネレータは動いているか？
    • ViewModel クラスが partial か
    • ビルド後に *.g.cs の中に AvatarImageClickedCommand が生成されているか

この 5 点を潰していくと、原因は必ずどこかで見つかります。特に BindingContext と x:DataType の不一致は、警告を読めばヒントがしっかり書かれているので、無視せずチェックするのがポイントです。

最小修正サンプル：まずはここから試す

すでに実装がある程度進んでいて、「とにかく手早く直したい」という場合は、次の最小修正サンプルを参考にしてください。

<sfPopup:SfPopup.HeaderTemplate>
    <DataTemplate x:DataType="vm:AppShellViewModel">
        <toolkit:AvatarView ImageSource="{Binding LocalUser.ImagePath}">
            <toolkit:AvatarView.GestureRecognizers>
                <TapGestureRecognizer Command="{Binding AvatarImageClickedCommand}" />
            </toolkit:AvatarView.GestureRecognizers>
        </toolkit:AvatarView>
    </DataTemplate>
</sfPopup:SfPopup.HeaderTemplate>

この修正で以下が同時に解決します。

  • AvatarView のタップで AvatarImageClickedCommand が確実に発火する
  • x:DataType を AppShellViewModel に統一することで、コンパイルドバインディング警告が消える
  • AvatarView のアイコン画像は LocalUser.ImagePath 経由で取得できる

この状態まで持っていければ、その後パターンBなどにリファクタリングするのも楽になります。

まとめ：.NET MAUI + SfPopup + AvatarView で MVVM を崩さずにコマンドを発火させる

.NET MAUI と Syncfusion SfPopup、CommunityToolkit の AvatarView を組み合わせたとき、コマンドが発火しない原因の多くは「イベントの繋ぎ方」と「x:DataType と BindingContext の不一致」にあります。

  • イベントのポイント
    • TapGestureRecognizer.Command を使えばシンプルかつ確実
    • EventToCommandBehavior を使う場合は EventName の指定を忘れない
  • x:DataType / BindingContext のポイント
    • x:DataType は型チェック用であり BindingContext を変えないことを理解する
    • パターンA：VM ベースで LocalUser.* とフルパスで参照
    • パターンB：テンプレートをモデルベースにし、コマンドだけ親 VM を参照
  • RelayCommand のポイント
    • [RelayCommand] で *Command プロパティが自動生成される
    • XAML では必ず AvatarImageClickedCommand のように *Command 側をバインド

これらを押さえておけば、SfPopup 内に限らず、DataTemplate を多用する .NET MAUI アプリ全体で「コマンドが発火しない」「BindingContext がよくわからない」といったトラブルを大幅に減らすことができます。特に、テンプレートと ViewModel の責務をどこで分けるかを意識して設計しておくと、後からの機能追加や画面の再利用もスムーズになります。

AvatarView からの画像変更やプロフィール編集など、ユーザー体験に直結する部分こそ、今回紹介したパターンA/Bでしっかりと MVVM を保ちながら実装していきましょう。

C#
.NET MAUI C# MVVM SfPopup Syncfusion AvatarView

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次