Choosers - inability to use Nested choosers with a "No primary result chooser"

Development Platform & Builds
, ,
1

Hello there, I’m trying to use a chooser just for the “Output struct” data, while not needing any real output object.

The “No primary result chooser” seems like a no-brainer, because it’s exactly what I need:

[Image Removed]

But the problem is that I can’t seem to find a way to add a nested chooser inside of this “No result chooser”:

[Image Removed]

I want to use nested choosers to aggregate some of the conditions and structure a big choosers into smaller chunks.

Is it just a UI problem (since the Result column is completely hidden in this chooser-type), or is it a design choice?

Thanks a lot!

[Attachment Removed]

2

Hi [mention removed]​,

From my investigation, this does not appear to be just a UI oversight. When the engine builds the UI, there are two different rendering paths: one for NoPrimaryResultChooser and another for the other chooser table types. You can find this logic in SChooserCreateRowButton.

For the NoPrimaryResultChooser widget, only “Add Fallback Output” and “Add Output Row” are constructed:

UChooserTable* Chooser = ChooserViewModel->GetChooser();
		if (!Chooser->FallbackResult.IsValid())
		{
			if (Chooser->ResultType == EObjectChooserResultType::NoPrimaryResult)
			{
				MenuBuilder.AddMenuEntry(
					LOCTEXT("Add Fallback Output", "Add Fallback Output"),
					LOCTEXT("Add Fallback Output Tooltip", "Add a Fallback row to the chooser, which will be used in the case where no other rows passed all filter columns"),
               ....
               }

if (Chooser->ResultType == EObjectChooserResultType::NoPrimaryResult)
		{
			MenuBuilder.AddMenuEntry(
				LOCTEXT("Add Output Row", "Add Output Row"),
				LOCTEXT("Add Output Row Tooltip", "Add a regular row to the chooser"),
                ...
               }

For the other chooser tables, the remaining widgets (including Nested Chooser options) are generated through a different code path in the else branch:

	else
	{
			MakeCreateResultMenu(MenuBuilder, Chooser->GetContextOwner()->ResultType, FCreateStructDelegate::CreateLambda([this](UScriptStruct* Type)
			{
				UChooserTable* Chooser = ChooserViewModel->GetChooser();
				const FScopedTransaction Transaction(LOCTEXT("Add Row Transaction", "Add Row"));
				Chooser->Modify(true);
 
         .........

What seems clear is that the UI construction goes through separate paths, and the NoPrimaryResultChooser builds a different set of widgets. Because of this separation, it looks more like a design choice than a UI bug.

It appears that this decision may have been made because all “Results” are removed from this chooser type. Even though a Nested Chooser could conceptually be used for internal structuring, it still returns a result to the parent chooser and is therefore treated as a Result type. Since NoPrimaryResultChooser is explicitly designed to avoid primary results, Nested Choosers are likely excluded by design.

A quick solution I see is to evaluate several smaller NoPrimaryResult choosers in sequence, write into the same output struct, and group the logical chooser steps into a method. So, instead of grouping everything into a single Chooser Table, you group them into a single function and call that function instead of a single Chooser node.

Hope this helps clarify the doubt. Let me know if anything remains in doubt.

Best Regards,

Joan

[Attachment Removed]

3

Thanks for your answer. Unfortunately, calling multiple choosers in sequence isn’t possible because the chooser is a result of a proxytable call. We want to let designers to structure this chooser as they see fit - grouping up results based on a similar condition etc.

Since it’s not possible, I will probably keep using a dummy AnimMontage asset.

[Attachment Removed]

4

Perfect Patrik! Will close the case for now but feel free to open it again if you want if you so decide.

Best Regards,

Joan

[Attachment Removed]