I have converted all our configurators and got them working. One issue I am running into is that the dynamic lists somehow leave a default value in the combo even if that value isn’t in the list. I have figured out how on load to clear the value. Inputs.Combo.Value = “”; I was hoping to find a way to set what was known with windows forms as the selected index. I can’t seem to find a way to do that. Does anyone have any suggestions?
Thanks
Matt
This may be the same bug I experienced. For example if I sell shoes in size 10, 11 and 12. Sizes 10 and 11 come in brown and black, 12 only in black. I have a size combo and color combo, the color combo is filtered based on the size and is refreshed after selecting a size
I pick size 10 and then Brown, but then change my mind and select size 12 the color combo will have the “value” for brown still there. If you open the color combo the list will be accurate in only listing black. What should happen is the color combo should become blank as it did in Classic Configurator.
I have a ticket open on this and it is in the pipe line to be fixed.
Rereading your post if you are seeing a value get loaded or visible in a combobox BEFORE the user does anything that would be a bug. A combo box should only get a value when the user either picks it or you load it programmatically.
To get the Kinetic Configuator really ready for prime time we need to be very diligent in submitting bug reports regardless of how minor they may seem.
To load a default value I create a list of them in a user defined table and pull from there to populate an initial value in a combo. Avoids any hard coding. The list needs to be kept in sync with valid values from the list used to populate the dynamic list. Another way would be to use a checkbox on the UD records used for the dynamic list if you don’t want to use a separate list. After refreshing the combo a simple lookup to find the record that is the default.
A better practice to “empty” a combo or any string type object is Inputs.cmbMyCombo.Value = String.Empty;
I am really not sure how it’s getting loaded at this point. this was converted through the epicor design in app studio checkbox. This one specifically is site selection and some parts aren’t available in all sites. The combo has no initial value or hardcoded values but still displays a site that isn’t in the list. I can clear it but the user is not used to selecting site every time. In classic the first one in the list was selected. Is that possible? I think this may be scenario one where a full list is loaded until something else triggers the filter and it doesn’t remove that option.
In classic configurator you used to be able to pass back a default value as part of building your dynamic list. I thought that ability was lost as part of Epicor 10 coming out. If that ability was still there and your configurator took advantage of it before you converted to Kinetic some attempt to keep it may still exist in Kinetic but if so it looks to not be working correctly.
One thought to check is if there is an initial value set in the combo properties.
There is no initial value set in the properties. I also built a program to read the json and xml files so I can search easier for issues we had converting. I looked to see if it was set in random code and it isn’t. This does give me an idea though. If I add a new combo set it the same way and get the same results it may be a bug if I don’t then there’s something setting a default value somewhere and I have to find it. Thanks for the input.
I have seen some controls in Kinetic configurator refuse to work properly but when rebuilt from scratch with the exact same properties they work fine. So your idea to create a new combo is worth taking a look at.
Hi Jim,
Did you ever get a solution for this or find a work around? I’m experiencing the exact same issue (combo box holding on to invalid values after dynamic list changes) that you outline here. I’m using Kinetic 2024.1.10.
Hi Jacob,
How are you populating your dynamic lists? Are you doing them through Lookup Tables or BAQ calls?
Lookup tables, using the Data Column Lookup List method.
Okay, gotcha.
Do you notice this issue occur whenever you modify the values in a given lookup table? For example, say you remove the “GRAY” color option from a table and save it.
Then, when you go to the test the configurator, is the “GRAY” color option still in there even if you removed it?
That seems to be the case, but I just want to make sure I understand because I think I may have a solution!
Hi Steen,
Sorry, I think I’ve been unclear! I am not modifying the data tables at all.
Say I have two dropdowns, one for color and one for size. The color lookup table contains “GRAY” and “BROWN”. The size lookup table contains “SMALL”, and “LARGE”.
However, the GRAY is available in both sizes, while BROWN is only available in SMALL. If I select BROWN from the start, it works fine - the filter works and only SMALL is available.
However, if I select GRAY initially, then select LARGE, and then go back and select BROWN instead, the size dropdown stays on LARGE. It stays that way even though it is not valid, and if I click the dropdown the only option is SMALL.
Does that make sense?
Thanks for explaining in more detail, I’m following now!
That is a bit weird. Sounds like it could potentially be a bug honestly, because I’ve run into quite a few with Lookup Tables and dynamic lists the past few months.
We’ve had to get pretty clever with workarounds to solve some of the issues that were holding us up with them populating incorrect values as well, but for different reasons and different scenarios.
I’m going to do some experimenting in our sandbox environment tomorrow, because I’m thinking the resolution to this will probably be an On-Load or On-Changed event that ties to the configurator session to constantly refresh the data as a user is going through it.
I’m sorry I don’t have an answer now, but I’ll have an update for you in the morning!
No problem - Thank you for looking into it!
Kinetic Dynamic lists not updating and clearing out when a value is no longer valid is a bug. It would be a loss of functionality from prior versions. I have an open a ticket on it.
You probably got the same answer I did - I asked Epicor and they said it was a known issue expected to be fixed in 2024.2.