hi all,
I have create three custom fields… booleen (for a check box), a string and a date. I have put them on them on a new sheet on the part screen. what i’m looking to do is when the user checks the box I want to record the user and the dates in the string and date fields respectfully… can any one direct my to a tutorial.
thanks in advance
I’m thinking since your UD fields are NOT part of the EpiDataViews of your form, it’s gonna be a bit more complicated than you hoped.
First, in Initialize you can call this which triggers your save code if Chk’d :
YouCheckBoxName.CheckStateChanged += (sender, args) =>
{
if ((sender as CheckBox).Checked)
{
DoSave();
}
};
The actual storing is more complicated and depends on the adapters needed
void DoSave()
{
//Your Code to Store Values - since your UD fields probably dont live in EpiDataView you'll have to
//1. Add a (wizard) reference to the proper adapter based on the type of record we are talking about
//2. Instanciate and BOConnect() said adapater
//3. Get data back from adapter related to your specific record GetRows(), GetByID(), GetList()
//4. Modify the data we just got back to add user\date (trivial) within the adapter
//5. Update() the adapter
//6. Destroy the adapter
}
I’m well know for overlooking simple solutions so if anybody else has thoughts I’m all ears.
A hacky (read: easy) way to do it would be create two EpiTextBoxes for your User\Date field. Name them. EpiBind them to the desired fields. Make them hidden. Then on save:
myUserBox.Text = ((Ice.Core.Session)oTrans.Session).UserID;
myDateBox.Text = DateTime.Now.ToShortDateString();
Hacky or not, I personally like the easy route described by @Chris_Conn, for this specific scenario. While complicated code is more often than not necessary on customizations (in my experience) and knowing how to do the complicated stuff is always worthwhile…sometimes, efficiency just wins out.
The requirements are simple enough (no conditions or complicated formulas required) that getting the UserID and the current time should not require more than a couple lines of code. The hidden fields allow you to easily get that information. Yay for easy fixes! Just because we can do things the complicated (read: cool) way, and tend to overthink things (so I’ve been told), doesn’t mean we should do it that way. Save the complicated code for the complicated stuff! 
There is another way that doesn’t involve programming… you can create a BPM that would record that information when the user clicks the SAVE icon. Assuming you’re on E10, download the EpicorICEToolsUserGuide document from EpicWeb and look through the Business Process Management chapter. Most likely you’ll want to create a Method Directive on the Part.Update business object.
Programming on the customization is a better way to go if you have the option… and as @Chris_Conn and @Trinity indicate, there are only about a thousand ways to code something like this.
@Ernie, I think that’s maybe one of the best parts of being a developer: the freedom to choose the option that works best for you in any given situation. We are problem solvers but there’s rarely just one way to solve the problem. Choose what’s best for you in each case - is one way easier? Your preferred way of doing it? Are you maybe trying to learn something new and this provides the perfect opportunity to put it into play? As long as the end result would give the same solution, it doesn’t matter which route you take!
I appreciate your input on this because it reminds me that just because I can write code to solve a problem, doesn’t mean a solution always needs to involve code; there are other ways of achieving the same goal!
I totally agree. I take a holistic approach to all my programming custom solutions. Maximizing the capability of the ICE Tools while minimizing coding requirements. In my environment, it’s not possible to have one area of responsibility as this enables the need to foster a development code environment that’s simpler to understand and maintain for the short and long term.
Best regards
thank you everyone for your responses
So acting on the given advice and speaking to an Epicor trainer , this is what I have done.
It doesn’t seem to be working.
private void epiCheckBoxC1_AfterCheckStateChanged(object sender, System.EventArgs args)
{
epiTextBoxC3.Text=((Ice.Core.Session)oTrans.Session).UserID;
}
any additional advice ?
why not a BPM?
That way if the field is changes via a DMT you are still tracking the user data.
We do the same thing here.
An if condition to check to see if the field has changed.
Then a set field to set the custom id field to callContextClient.CurrentUserId
Then a set field to set the custom date field to BpmFunc.Now()
That way if the field is changes via a DMT you are still tracking the user data
As a server geek, this always destroys me. So many people just think about one client and not all the other ways data can be sent to the server.
If you do an integration or use EWA or Mobile CRM, etc. Do you still want some piece of functionality to track this information? I would assume you don’t want an audit trail hole that you can drive a semi through. Use server code - a BPM.