An issue we are experiencing in product configurators is that when a combo box dynamic list is refreshed, while not being focused, the value displayed in the UI becomes the actual combo value instead of the combo description.
For an example, a simple configurator that only has two combo boxes, combo1 and combo2.
Both combo boxes are set for a dynamic list, populated by a UD method (GetList). The UD method code is dynamic depending on the current option selected in combo1. The logic being that if combo2 has Item B selected, no combo is able to select Item A.
Since the contents of each combo box depend on what is selected in combo2, the dynamic list needs to be refreshed every time the selection of combo2 changes. A refresh to dynamic lists is added to the ColumnChanged event of combo2.
The filtering works as expected, but if an option is selected in combo1, and the refresh event is triggered on combo2, the description for combo1 becomes the value for some reason in the UI. It is important to note that this is only on the UI. The property of combo1.Description is still “Item C”.
Before selecting anything in combo2:
After selecting anything in combo2:
I am curious if anyone has any suggestions on what is happening here, or if there is a different intended way to make this functionality work? It could just be that this is a bug.
A funny workaround is to reset the description of a combo box after the refresh, but that makes for a less than ideal user experience (plus a significant delay in results when in a more complicated configurator).
If the Combo Box is not set to load dynamically from a UDMethod, and instead populates from a static list, the Description does not get reset when the Dynamic List Refresh happens.
I would recommend being very judicious with the use of “Refresh.DynamicList()”, this will cause all combos to refresh and to your point cause additional delays. As your configurator grows, this is harder to maintain and introduces a lot of unnecessary refreshes. You can specify the combos you want to refresh specifically by listing them Refresh.DynamicList(“combo1”, “combo2”);
Sometimes I find it more efficient to let the combo determine when it needs to refresh, place the refresh dependencies on the target combo instead of the other inputs. This way all the “logic” is in one place.
To do this simply reference each dependency in the Dynamic List condition. Similar to what you did with the UDMethod.
string combo2Value = Inputs.combo2.Value;
You can keep your condition logic, just include a reference to the combo above your condition. Your condition does not even need to use the reference.
If you use this method then you can remove the forced “Refresh.DynamicList()” on the OnChange events.
Hey Aaron, thanks for the advice and tips. I like the idea of removing any call to “Refresh.DynamicList()” and referencing each combo input in the Dynamic List Condition.
Unfortunately, I plugged that solution into my simple example, and I am still seeing the combo box description bug. The refresh still works as intended, but if any combo box is not focused when it’s list gets refreshed, the description changes to be the currently selected value instead of the description (Item A → A).
I don’t think he meant it to resolve the description bug. But it would enable you to use the workaround you found of resetting the description without the penalty from updating every dynamic list.
I see. Unfortunately, my Companies configurators are pretty complex, and a lot (if not all) combo box lists change based on the selections of the other combo boxes. We found this to be the best user experience for how our business uses Epicor, and worked fine in 10.2.400.
For a little extra background, the investigation into this bug is to aid in the upgrading (from 10.2.400 → Kinetic) of an automated tool we created internally to generate the import/export files for a configurator based on only knowing the inputs and rules. This means the more general the solution, the easier the implementation there.
I may be on the verge of a very Epicor-like workaround here though. I have discovered that this bug only occurs if the refresh is attached to the combo_ExecuteCsharp_ColumnChanged event (meaning calling the refresh in the event, or inferring it by referencing an input in the Dynamic List Condition). The bug does not happen when refresh is called from another event, for example, button_ExecuteCsharp_ColumnChanged. With this, by attaching an event-next element to the OnBlur event of the combo, we can call a refresh after a user moves to another input. This obviously isn’t ideal, as the user will assume they are free to use the UI, only for it to be locked up as soon as they switch inputs. I am looking into changing the focus in the column changed event and will post back once I have a more concrete solution that I feel confident in.
I’d love to know more about this. I’ve created / admin’d / migrated some very complex Configurators as well, with a lot of dependent selections and drop-downs. This sounds like a really interesting tool.
For a final update, we found a “fix” using the workaround I mentioned in the OP. This does not only work as a workaround, but actually prevents the bug from happening, as long as it runs when the combo is not focused. By placing the code inside of the OnBlur event for a combo, the bug never occurs again for that combo. Note that the code must be run every time the combo selection changes, however.
Without the fix, when both of the following are true, the bug occurs.
When a combo box is not focused and the dynamic list refreshes
When the combo_ExecuteCsharp_ColumnChanged has any event elements running inside it
Our initial plan to move all logic in the ColumnChanged event to the OnBlur event did work in avoiding the bug, but with complex calculations happening between combo selections, this caused a bad user experience. The next clicked combo would expand just for the UI to lockup, as well as other weird behavior.
A final interesting tidbit about this fix, the code only needs to be run one time per combo every time the combo selection changes. The fix does not need to be run every time the combo refreshes.
It’s nothing crazy, just a winforms app with templates for the XML and JSONC files that get generated when you export a configurator in Epicor. The app uses the templates and injects any events and controls that are unique to that configurator. We were originally using this for 10.2.400 and recently upgraded to 11.2.400. We have plans to leverage the new functionality from upgrading (functions, asynchronous processes, etc), but are currently just trying to get to a working state of this application so we can uplift all of our configurators more easily than recreating them from scratch in App Studio. The Auto-Conversion process for our use case just ends up corrupting each one.
