That’s a lot of background work to get show simple drop down bug. Is there any way to get this into the hands of someone who understands the background needed to submit this without having to submit a click by click creation of the UD tables fields and User codes? I only ask because I have had to send a click by click document to service where 90% of it was standard functionality.
1 Like
Put in a call and then send me the Customization and Call Number.
I am not seeing any issues with the UD Code Type combos - tested at 10.2.200 and 10.2.300 - but I did not test with the Combo added to a grid. Irregularity seen by @hkeric.wci was likely corrected in or before 10.2.200.
Keep in mind that when you Refresh the list via the context menu you are essentially clearing the value previously set on your binding. I believe we actual retain the value but lose the Index position for the value and display when the list is cleared / refreshed and if you don’t select anything after the Refresh and then move out of the field, it is the same as entering the field and then deleting the value.
2 Likes
Thank you Rich. After hours today I can create a Test Case and Submit a Call. I also have E9, 10.1 and 10.2.300 - I can load the .cab in 10.1/10.2.300 and see what results I get and i’ll post back an update.
We’re seeing the same thing on 10.2.300.10. Should we enter a case as well or piggy-back on someone else’s?
Ours is NOT on a grid.
@Rich @hkeric.wci Either of you have the case # or SCR I can reference? Put a call in to support today and was told that support cannot deal with this issue as it is a customization and needs to be handled by the person that did the customization.
I just made a post about this issue! Epicor says it is not their issue??? It worked fine for us in the current version, but upgrading to 10.2, no longer works…?? how is it not Epicor issue?
Pierre
1 Like
Because you used “the c-word” 
1 Like
If it is indeed intended behavior then it needs to be added to the Documentation stating so. The following pages should be modified:
to indicate the designed behavior. Maybe a call-out like this?
Oh my, I think I pinned the sarcasm gauge…
2 Likes
The issue is currently in the Development review queue and was raised to me yesterday for my comment / thoughts as the way it is written up (and without proper understanding of the Combo behavior), it could be interpreted as an Enhancement.
This is clearly a bug and we will address it. The problem is that when the User Code Combo gains focus, we fetch the Value - Description list from the Server and since the Value on the record is currently tagged as Inactive, it is not in the list. As a result, the original value on the Record does not display and cannot be selected. By setting focus to the Combo, the user has inadvertently changed the record.
We dealt with a similar issue in the early Vantage days with the Retriever Combos. The Rule for the Retriever Combo was that if the Combo List (Value - Description) did not contain the Value currently on the record, the List needed to be updated with the Value from the Record. With that change, the user is always able to leave the selection as it was prior to the field getting focus.
Due to the way the Epicor dataset is constructed, that was pretty easy to do as the data row contains both the Value and the Description. In this case, I have requested that the original Value should get added to the List with a Description of the value and some text to indicate it is Inactive or Deleted. For example, if the inactive User Code was “Yellow” the description for the code would be “Yellow (Current Selection - code inactive or deleted)”.
I do realize that instead of "Yellow (Current Select - code inactive or deleted) " we could go back to the server to try and get the actual description but I believe that this provides more feedback to the user (How come I can pick Yellow on this record but not of this other one?) while also not adding additional processing time to a “get focus” event.
2 Likes
Rich - your post is the first to bring “inactive” into the conversation. Is this what the original posters’ issues were?
Or was this an example combo boxes populated by list, which doesn’t contain the value the control is bound to - and is just similar in the root cause?
“Inactive” value issue is the one that came through development on Monday.
I believe that the “pile-on” of this thread is due to more than one issue -
An issue that has already been addressed
An Issue with “Inactive” Code Values
A possible issue when a customization includes multiple and different User codes
We will do some extended research and QA as part of the work to resolve the Inactive Code issue.
3 Likes
This would be our case. We have six UD Fields with six different UserCodes and only one combo exhibits the blanking problem. If you want, I can create a new case or if there’s an existing case then we can be added to that one. Thanks again @rich.
Mark W.
only one has the problem - interesting. Please ensure that all the DropDown and Type property settings are the same for all the Combos and then create a new Tech Support case and send me the number.
3 Likes
@Rich I had a 1.5 hour session with support yesterday, they took loads of information. The case # is CS0001401754.
3 Likes
For anyone that is interested, the problem case that was created in regards to my support call is PRB0210947. So far I have not heard back since it was created.
2 Likes
Hi
Did you try making [RetrieveOnActivate] = False?
Cool. That should be on next week’s monthly update then.
I found this thread after running into something similar in 10.2.100.36. We’re planning to upgrade soon, so I’ll see if the problem still exists in the newer version.
I followed the instructions in this thread to put a combo box in a grid. The combo box already existed elsewhere in the form. Both combos initially look correct, and both save the correct values when changed and saved. But when the combo in the grid is changed, the original sometimes goes blank. Sometimes it refreshes if you switch tabs a few times, sometimes not.