Hi Euan,
Thanks for helping me with this!
I noticed this issue when I was trying to evaluate a chooser in code. I assumed that I had to provide context data in the same order that it appears on Chooser Table but it seems to not be the case.
Let’s say I have first added StructA to my Context Data in my Chooser Table. Let’s also say that the first Column is an Enum Column that is bound to StructA->EnumVariable. At some point later, I add StructB to my Context Data and change the first Column’s type to Bool and bind it to StructB->BoolVariable. On the code side, I create an FChooserEvaluationContext and add my StructA and StructB instances to it, and call Chooser->ChooseMulti. Now consider the following 2 scenarios:
1- In my FChooserEvaluationContext, StructA is at index 0 in Params and StructB is at index 1 in Params. Chooser->ChooseMulti behaves as I expect.
2- I go to my Chooser Table and change the order of Context Data in Settings. So now StructB is before StructA in my Chooser tables’s Context Data section. Since the order has changed, I change my FChooserEvaluationContext in code to have StructB at index 0 and StructA at index 1. To my surprise, I see the chooser evaluation is incorrect. I debug it and I notice three issues:
A) Even though their order has changed in my Chooser Table and StructB is now before StructA, the bool column’s FChooserPropertyBinding::ContextIndex is 1. So it expects StructB to be at index 1!
B) When it grabs StructA from index 1 (because StructA is at index 1 instead of StructB) and looks for the bound bool property, the search fails. However, the code doesn’t check that InputValue.Get<FChooserParameterEnumBase>().GetValue(Context, Result)) has failed and just continues assuming that the value of Result is false. When in fact Result is invalid because the code has failed to find the bound property.
C) All my other chooser table columns are enums and bound to variables from StructA. The search for them fails too because the code expects StructA to be at index 0. However when the check for InputValue.Get<FChooserParameterEnumBase>().GetValue(Context, Result) fails, this piece of code runs:
else { // passthrough fallback (behaves better during live editing) IndexListOut = IndexListIn; }So all the rows pass through, when I would have expected no rows to pass through because Result is invalid.
So I wonder if:
1) It is also a bug that when I change the order of Context Data in chooser table, FChooserPropertyBinding::ContextIndex for the columns doesn’t get updated? I tried to look a bit on the code side to understand how ChooserEvaluate custom node generates FChooserEvaluationContext and how it orders the Params but I couldn’t figure it out. I only noticed that changing the order of Context Data in chooser table, changes the order of input pins in the Evaluate Chooser node as expected.
2) It is a bug that when the Result validity check fails, all rows pass through the filter?
Kind regards,
Maryam