I’m working on a UD customization (using UD11) where the intent is to allow a user to search for a specific Non-Conformance record and return a handful of pertinent values from the NonConf adapter. The user will then continue with the task of entering key data points that illustrate the agreed-upon disposition and the Engineering substantiation for that disposition along with sign-offs by each of the engineers involved in the process.
In testing, the Non-Conformance adapter search method pulls back the correct data and populates the intended fields with no problems. After adding values to the other fields, I save the record. However, a peek into the UD11 table shows that all values are saved except for anything that gets populated into the “sign-off” textbox controls. These textbox controls are no different than the others that have been configured on the form with their EpiBindings to UD11 well-defined. The textboxes that do not save are all set to “ShortChar” fields that have a 50-character limit (my name being used in this test only has 12 characters).
Here is the C# for the Non-Conformance adapter search method:
Can anyone detect what I might be missing, or perhaps if my approach to this is not the way I should be doing it? Admittedly, I’ve made quite a few assumptions during this particular task relating to the idea that I could save search adapter values along with usual data value inputs within the same data view structure. However, if this is not so - then why would the other values, such as “cboDisposition”, “txtDispDetails”, and “txtSubComments” process through this method without error?
That all looks fine, for giggles can you set ShortChar09 to “Sup Dude!” and see if it saves?
Also make sure the fields are ShortChar09 (with a capital C) sometimes things are more sensitve than others.
I’m also assuming those textboxes had a value right? In your screenshot they are empty/
The “MRB QC” (ShortChar09) value gets populated right when the search call is made to the NonConf adapter, which makes sense, because we’ve given it a hard value right off the bat.
As you can see - that value does get saved to the UD11 table.
(Yes - the sign-off values were in place on the form when I had tested previously)
Could there be something interfering with the data view since those four sign-off textboxes are the only ones that I have applied customized button functionality on (to both populate and clear them)?
Ok. I have since discovered through additional testing that it might be an issue with the customization I’ve put in place to populate those fields via the “Sign-Off” buttons.
When I don’t use those buttons (which merely take the “epiSession.UserName” value and populate whichever textbox needs to be “signed”) and, instead, type a name value directly into the textbox… it saves the value properly.
Sorry I’m responding late on this, José. I was out on a stay-cation during the past week.
The textboxes are bound in the data view shown below as “edvUD11” - BUT - they are mapped during the search function call on the “NonConfAdapter”. I have a hunch that those data view bindings are being defined prematurely in the wrong spot:
I discovered a bit of a workaround (perhaps the solution?) to this problem.
First, I removed ALL of the data view bindings within the NonConfAdapter block that aren’t related directly to the NonConf search function. I didn’t think those were needed since the only purpose of this section of the code is to bind the returned values from the adapter to the data view.
Then, since the textbox controls seemed to save only if either [1] something is typed directly into a textbox (focus given; value provided), or [2] a textbox control had been given focus manually after clicking on one of the “Sign Off” buttons (value provided; focus given), I decided to code in a “set focus” function as part of each “Sign Off” button code block. Essentially, the “Sign Off” button sets the Epicor session user name directly into the appropriate text box and then places focus into the same text box (value provided; focus given).
The record (data view) now saves successfully to the database.
Not sure if this is the best practice way of doing this, but it works.
