EpiCombo with UserCodes going Blank on Click

In my examples, it’s one combo, with one set up user codes. The combo in the grid changes itself automatically.

1 Like

Ah I see, I did have some weird issues about a year ago when trying to bind a combo into a grid. As I recall, I ended up writing my own handling from scratch. I wish I could think of which project it was and I’d revisit it.

1 Like

Sounds like a ping to @Rich is in order.

3 Likes

What Version?

In looking at Change history there were several changes made for 10.2.200 that looked to be correcting issues reported against 10.1.400.

I am in 10.1.500.46

I’m in 10.2.200.13

It looks like there was one change made for 10.2.300 that might correct this. Please place a call with Tech Support and include customization that shows the issue. We will need to research to see if this issue is still present.

2 Likes

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” :wink:

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?

image

:thinking:

Oh my, I think I pinned the sarcasm gauge…

:rofl:

@Rich @hkeric.wci @jwmartin @Staci_Stahr_Cummings

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?

Thank you @Rich for helping with this!!!

“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.