ブレークポイントを使ったデバッグではウィンドウのフォーカス変更がトリガーされることがあり、それによってアプリケーションのウィジェットのフォーカスが影響を受ける可能性があります。ブレークポイントにより、デバッグしようとしている UI のステートが変わってしまうことがあるため、これによって入力のデバッグが困難になります。条件付きブレークポイント を使用することで、この制限を回避できる場合があります。
ヒット カウントを使った条件付きブレークポイント
条件付きブレークポイントの最も簡単な作成方法は、ブレークポイントに ヒット カウント を加えて、数回のクリック後にブレークポイントをトリガーするやり方です。
Visual Studio でヒット カウント条件を使った条件付きブレークポイントの例。
ヒット カウントを追加したら、最後のクリックで目的のウィジェットがクリックされることを確認します。
ヒット カウントなどの条件を設定する方法の詳細については、IDE のドキュメントを参照してください。
ウィジェット リフレクタを使った条件付きブレークポイント
ウィジェット リフレクタ (Widget Reflector) を使って、特定のウィジェット向けの条件付きブレークポイントを作成できます。これを行うには、ウィジェットを特定してその [CBP] をクリックします。これにより、ブレークポイントがそのウィジェットのみで有効になります。たとえば、特定のボタンのみに対してトリガーされる SButton::OnMouseButtonDown にブレークポイントを加えることができます。
![The [CBP] button in the Widget Reflector](ClickCBP.png)
CommonUI 入力のトラブルシューティング FAQ
以下は、CommonUI を使用するデベロッパーが頻繁に直面する問題や、デベロッパーからよく寄せられる質問の FAQ です。
ティック / ゲーム ポーズによって UI が影響を受ける問題をどのように回避できますか？
現時点で CommonUI は LocalPlayerSubsystems で機能します。ゲームのポーズ中はこれらのサブシステムがティックしなくなり、それによって CommonBoundActionBar を含む CommonUI が機能しなくなります。その回避策として、UI の意図した機能やパフォーマンスと矛盾しない限り、関連するアクタとウィジェットを ポーズ時にティック可能 に設定することを推奨します。必要であれば、カスタム仕様の子クラスを派生してこれを行ってください。
キー ハンドラ メソッドでアナログ入力が取得されるのはなぜですか？
UE5 では、InputKey と InputAxis の動作が PlayerController レベルで統合されています。当社では、偽の入力インジェクションと入力パラメータのバンドルを行いやすくすることで、将来の更新を簡単に行えるようにすることを意図しています。
UE 5.0 以前からのコードを使用している場合は、アナログ入力によってキー ハンドラのコールバック (もしくはその逆) がトリガーされることがあります。CommonUI は、これによって何らかの意味を持つエフェクトが生じないように適切に保護されていますが、入力パイプラインで早期にデバッグを行う場合は、このクロストリガーが多少生じることがあります。たとえば、FCommonAnalogCursor は入力プロセッサであるため、入力パイプラインの早期段階で相互処理 (インタラクション) を行います。この相互処理のため、FCommonAnalogCursor::HandleKeyDownEvent でクロストリガーが生じる場合があります。
入力モードがメニューである場合に、ゲーム入力が取得されるのはなぜですか？
UE5 では、ゲーム ビューポートにマウス キャプチャがある場合、UCommonUIActionRouterBase::CanProcessNormalGameInput によってメニュー モードでのゲーム入力を許可しています。これにより、メニューにいる場合に、ワールド内のプレビュー アイテムとキャラクターの操作に対するサポートが強化されます。この動作を望まない場合は、目的の入力コンフィグでビューポートのマウス キャプチャを無効にしてください。