本現象についてプラグイン開発元であるCRI社へ問い合わせを行ったところ、以下の回答を得ております。
TOptional の切り替えに伴うDetailsパネルの再構築処理が発生した際、UAtomSoundCue 側に実装されている IPropertyTypeCustomization::CustomizeChildren() の呼び出しが行われないことが直接の原因になっていると思われる。
こちらについて意図した挙動かどうか、なにか情報はありますでしょうか
本現象についてプラグイン開発元であるCRI社へ問い合わせを行ったところ、以下の回答を得ております。
TOptional の切り替えに伴うDetailsパネルの再構築処理が発生した際、UAtomSoundCue 側に実装されている IPropertyTypeCustomization::CustomizeChildren() の呼び出しが行われないことが直接の原因になっていると思われる。
こちらについて意図した挙動かどうか、なにか情報はありますでしょうか
再現手順
UPrimaryDataAsset を継承した C++ クラスを作成し、以下のプロパティを配置する。TOptional 変数を含む構造体プロパティ(または TOptional 関連プロパティ)UAtomSoundCue* プロパティ(IPropertyTypeCustomization により独自描画が実装されているプロパティ)TOptional の有効/無効チェックボックスを切り替える。UAtomSoundCue プロパティの表示が消失する。
AtomSoundCueに関してはエンジン内にクラスがないので適当なクラスを自作し試してみましたが問題を確認できません
「プロパティの表示が消失する」について具体的にどうなるのかご説明頂いてもよいでしょうか?
素直に受け取るとプロパティの行が丸ごとなくなったり、値のカラム部分になにか異常が出て操作に支障が出る状態になっていると思うのですが、特になにも起こりません。
またエンジンの中にあるクラスで同じ状態を再現できるサンプルやコード例がありましたらご共有ください。
以下はDataAssetの操作後のスクリーンショットとデータアセットの定義です。
UCLASS(BlueprintType)
class UReproOptionalDataAsset : public UPrimaryDataAsset
{
GENERATED_BODY()
public:
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Repro|2. Customized")
TOptional<UReproSoundCue*> OptionalSoundCue;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Repro|2. Customized")
TObjectPtr<UReproSoundCue> ObjectPtrSoundCue;
わかりにくい説明ですみません
CRIさんはかなり特殊なことをやっているのでエンジンで同様なものがわからなかったのでスクリーンショットでご説明させてください。
1枚目はTOptionalな値とAtomSoundBaseクラスのプロパティがならんだDataAssetです。
2枚目はその状態でTOptionalの有効無効を切り換えたことにより、2行目のAtomSoundBaseの詳細が描画されない状態になったスクリーンショットです アセットを開き直したりコンパイルすると再び正常に表示されるようになります。この件についてCRIさんに調査をお願いしたところ、直接の原因は
IPropertyTypeCustomization::CustomizeChildren()
が呼び出されないことで、それがエンジンの使用なのか不具合なのかわからないとのことでしたので、なにか情報がないかおうかがいしてる次第です。
よろしくお願いします。
大変恐縮ですが、一枚目の画像が TOptional有効化前で、切り替えると2枚目でなんらの影響がでてご不便をおかけしているのだと思いますが、どの行がどれに対応するのかプロパティ全体が見れないため
状況をつかめません。
おそらく近しい問題として以下のリンク先で議論されているバグがございますが、Toptionalの挙動については現時点では大きな改善が見込めない状態です。
コードの修正を伴うため体現心苦しいですが、UPROPERTY定義の InlineEditConditionToggleやEditConditionを使った定義をご利用いただく方法に切り替えていただくことをお勧めさせていただきます。
1枚目にあったサムネールを含む要素がまるっきり2枚目で表示されなくなって次の行以降が表示されている状況です。
1行目が同じプロパティを指しています。
リンクで頂いた状況は継承に関連したものですが、こちらは単に表示上の問題です。
弊社としては現在実際に変更した実装で回避しているため、作業の上での問題はありませんが、エンジン側の挙動として
IPropertyTypeCustomization::CustomizeChildren()
が呼び出されないのは正しいのか今後修正される物なのかを確認したかっただけです
TOptionalのUIがあまり推奨されていないこともあり、バグとしてまた未登録のため見落とされている可能性が高いです。
出来れば再現に繋げてバグ登録することができれば、将来の修正に担当をつけることが出来るので再現につながる情報を頂けると大変ありがたいです。
お休みを取っておりまして回答遅れました
こちら、一旦CRIさんの方に情報共有してみます
承知しました。宜しくお願いします。
CRIさんとお話しして、とりあえず該当の箇所を教えていただきましたのでこちらの方でサンプルプロジェクトを作成しようかと思います
ただ、ちょっと他の業務詰まっておりましてお時間頂くかと思います。
よろしくお願いします。
かなりシンプルなテストプロジェクトを作成しました。
展開してビルドしていただき、Content/NewDataAssetを開くと以下のようになるかと思います。
1行目がFTestCustomizationを使用してカスタマイズしているSampleAssetクラスです。
現象の再現目的ですので、内容には特に意味はありません
この状態でSet to Valueを押すと
このように1行目が非表示になります。この状態で一度アセットのウィンドウを閉じて開きなおすと、再び1行目が表示された状態になります。
この現象が意図した挙動になるのか不具合なのか、ご確認いただけますでしょうか。
MyProject.zip(11.4 KB)
再現プロジェクトのご用意ありがとうございます。問題を再現することが出来ました。
アセットを開いたときの一回目は正しく表示されるのに関わらず、TOptionalの有効無効を切り替えてUIの全体再構築が行われると要素が消えてしまうのは
FTestCustomization::CustomizeHeaderで呼び出されているMarkHiddenByCustomizationが原因です。
この関数はプロパティのノードにEPropertyNodeFlags::IsCustomized を付与し、UI構築時にそのプロパティをスキップするように指定します。
一回目だけ正常に動くのは FTestCustomization::CustomizeHeader の呼び出しが、このフラグの判定の内側のブロック(FDetailCategoryImpl::GenerateNodesFromCustomization参照)で行われるためです。
コールスタックの一部を抜粋します。
<<<<< ↓Customized フラフ設定 >>>>>
UnrealEditor-NewModule.dll!FTestCustomization::CustomizeHeader(TSharedRef<IPropertyHandle,1> PropertyHandle, FDetailWidgetRow & HeaderRow, IPropertyTypeCustomizationUtils & CustomizationUtils) Line 17 C++
UnrealEditor-PropertyEditor.dll!FDetailPropertyRow::OnItemNodeInitialized(TSharedRef<FDetailCategoryImpl,1> InParentCategory, const TAttribute<bool> & InIsParentEnabled, TSharedPtr<IDetailGroup,1> InParentGroup) Line 383 C++
UnrealEditor-PropertyEditor.dll!FDetailItemNode::InitPropertyEditor() Line 173 C++
UnrealEditor-PropertyEditor.dll!FDetailItemNode::Initialize() Line 61 C++
<<<<< ↓Customized フラグ参照 >>>>>
UnrealEditor-PropertyEditor.dll!FDetailCategoryImpl::GenerateNodesFromCustomizations(const TArray<FDetailLayoutCustomization,TSizedDefaultAllocator<32>> & InCustomizationList, TArray<TSharedRef<FDetailTreeNode,1>,TSizedDefaultAllocator<32>> & OutNodeList) Line 1147 C++
試しにMarkHiddenByCustomizationの呼び出しを削除すると2回目以降の再構築でもレイアウトが崩れることなくレンダリングされるようになることが確認できました。
この関数呼び出しが意図したものかご確認いただけますでしょうか。
実際のCRIさんのプラグインでも同様の箇所をコメントアウトすることで正常にレンダリングされることを確認、CRIさんに確認をとったところこちらの対応で問題ないということでしたのでこちらで解決といたします。
調査ありがとうございました。