Control State After UD Form Save

Might anyone know how I might be able to control/direct the state of UD form controls upon record save so that all controls on the UD form are converted to a “read-only” state? The UD form customization that I’m working on is meant to be a data-entry form, not a tracker - so I’d like the record to be saved and “locked”, unless a user needs to re-access the record to edit it.

Below is a depiction of current behavior:

You’ll notice in the bottom panel, the expected/needed behavior as exhibited by the NonConf search field. I’d like to see if I can get all other controls to mimic the read-only state upon record save.

Might there have been something to which I should have paid more attention during creation of the UD form?

Use row rules where RowMod != “A” make the fields read only. You’ll end up doing some custom conditions i believe.

Joshua - I’m confused how to get that set up because the definition of a rule condition seems to be limited to choosing a specific field on the data view. More specifically, the rule condition as I currently see it, should be evaluated on “row save” (when a record is saved)… but the row rule dialog appears to only allow evaluations on fields in the data view rather than a row action on the form itself.

Example:
What I think I need to do -
“Did the user just save the data entered on the UD form?”
Yes - Set the ReadOnly property on all form controls to true.

How I’m interpreting what’s available in the row rule dialog:
“Does a specific condition exist for a specific field in the data view?”
Yes - Set a EpiReadOnly style on all form controls (perhaps accomplished through a custom code action)


Maybe I’m not thinking this all the way through; perhaps unable to witness the firepower of this fully armed and operational battle station wizard?

emporer

in custom code action, you should be able to do:
args.Row[“MyField”].ReadOnly = myBoolValue;

Chris -

I see where this would allow me to set the read-only property for a specific field to true or false, but…

My confusion is more with understanding the set-up of the Row Rule Wizard… because my mind is thinking I need to evaluate the state of a record/row (in this case, upon the deletion of a row), but the Row Rule Wizard is merely evaluating various conditions of a field (not a record/row).

row-rule

I’ve skimmed through pages 457-484 of the Epicor ICE 3.2 Customization User Guide, but the examples provided are solutions to highlight certain form fields, or modify text and properties of form fields when a specific field meets a defined condition.

I will concede that, during my testing, the NonConf search field is the only field out of all fields on the form that automatically reverts back to the desired read-only state upon record/row save. Perhaps, this is where the evaluation of a field condition might work?

You can use a RowRule of RowMod not equals (or equals) ‘A’. I am assuming you want to be able to set a value on a new record, then once saved, it’s forever locked.

Even better so on the action, you mention you want to lock ALL UD controls, just put all those controls on a groupbox, and disable/enable it

I just tried to look at the possibility of evaluating off of the NonConf search field and determined that it can’t happen because NonConf is not part of the available rule views.

NonConf (or whatever the name of the EpiDataView is - determined with field help) should most definitely be in the list of selectable views for you to perform a RowRule condition against.

Yes… the UD11 view is in the list and I believe that’s the one I need. I only mention NonConf because I’m using that to map search fields through its adapter (and the searched NonConf.TransID field is the one that reverts to read-only upon record/row save). UD11 is definitely in the list, NonConf is not.

Oh that isnt the nonconf screen, is it a complete custom?

I’d say you have 2 options (at least):
Simply use UD11.RowMod != ‘A’ to set your controls disabled
Use an FKV, link back to the NonConf table, then you have a nonconf epidataview to use as you like.

I’m assuming that your nonconfid box is actually Key1. Base functionality is once you enter the key field, it doesn’t let you change it, (because it’s a key field).

You might be able to match the state of that field (key1) to set the read only of your other fields.

1 Like

Good call, i’ve got a snippet somewhere on the forum for just that.

Chris:

I should have provided a bit more information concerning my solution. Correct - this is a customization for UD11 (Ice.UI.App.UD11Entry.UD11Form).

So, we have this additional level of data tracking that we need to perform specific to FAA requirements relating to decisions made within the NonConf-to-DMR-to-Disposition process. Our engineers and QC staff need to provide substantiations (according to FAA regulations and various other engineering best practices) for dispositions on scrap, or perhaps if a part is to be used “as is”, or if the part should be reworked. Our team needs a way to enter those decisions, the substantiations behind them, who made the call on the Quality side, who made the call on the Engineering side. So, even though Epicor ERP has a nice way to enter non-conformances and track dispositions through DMR, my company has all of these extra steps we also need to track.

The best way I thought to do this was to make a few small customizations in NonConf… and… then work in the disposition and substantiation model via a UD table.

That’s the piece I’m working through now. I chose UD11 and had already set up the table and a few fields on the UD11Entry form to correspond with UD11’s available fields. The NonConf search was needed so that our engineers could simply look up the originating non-conformance record as a reference. Various required NC data would then be included in the final disposition/substantiation report.

I wanted “Key1” to hold an auto-generated number (that’s a discussion for another time :neutral_face:) that represents a PK for the UD11 table and use “Key2” as a FK to the NonConf table… which also makes me wonder if there might be some additional UD configuration I need to be doing to ensure the Epicor system knows about the [UD11.Key2]-to-[NonConf.TransID]" relationship.

Anyway, the three-panel screen grab I started with above is depicting the UD11Entry form as it stands now. An engineer can open the form, reference the originating NonConf… then get to work on entering disposition and substantiation. All of this saves nicely back to the UD11 table in the appropriate fields (nothing is done to the NonConf table, as it’s merely a lookup).

However, the UD11Entry form leaves all of the fields accessible to adjust or modify directly after the data on the form is saved. I’d prefer to adjust all form controls to “read-only” when a record-save is enacted.

What I don’t know how to do is “detect” when a form save has been called in order to adjust the read-only property on all controls on the form. Row Rule Wizard has been suggested. Perfect… but how is a form save “detected” using Row Rule when it appears the Row Rule (at least in my interpretation of it) is merely looking at conditions that can be defined on a field?

Where does “UD11.RowMod != ‘A’(where the RowMod property of the UD11 table does not equal ‘add’) fit in to evaluating a condition on a field? Which field(s) should this evaluation of the entire table be applied?

My confusion is… how does an evaluation of conditions on a field (this is what I believe the purpose of Row Rule is) fit in with saving an entire record/row on the UD11Entry form?

Ok… in keeping with the dreaded Star Wars theme I morosely started, I feel like tossing up a Princess Leia GIF with the caption, “Help me, Obi Wan Chrisnobi. You’re my only hope”… but that would be even more cheesy than the Palpatine reference.


Postscript:

The two main drivers behind this are that [1] saving the record with no visible change in form/controls state might confuse the user concerning whether or not his/her data had been saved at all and [2] I’d like to prevent accidental data modifications should the user keep hitting the save button during his/her confusion.

I’m not sure how @jgiese.wci was intending for the row rules to be used, but you need some event to key off of. RowRules could work, but like you said, the RowMod doesn’t show up in the items to choose, so I would imagine that you have to hack it.

If it were me starting this, I would prototype the read only part and tie it to a button just to see if you can get the fields to follow the Key1.ReadOnly property. Create a method to set the properties and then call that from a button event. If you can get that to work, then all that is left to do is to find the appropriate event(s) needed to make the switch. I would probably start with an after update event with update being my first choice. If you make the method compare the property of the key1 field than you can call the same one after the getnew method. Whatever works.

If you want to use the row rules method you can’t use the wizard. Otherwise if you want to use something more familiar use the EpiViewNotification initalize

private void edvUD11_EpiViewNotification(EpiDataView view, EpiNotifyArgs args)
	{
		// ** Argument Properties and Uses **
		// view.dataView[args.Row]["FieldName"]
		// args.Row, args.Column, args.Sender, args.NotifyType
		// NotifyType.Initialize, NotifyType.AddRow, NotifyType.DeleteRow, NotifyType.InitLastView, NotifyType.InitAndResetTreeNodes
		if ((args.NotifyType == EpiTransaction.NotifyType.Initialize))
		{
			if ((args.Row > -1))
			{
				// If the row is in an added state enable the fields
			        field1.IsEpiReadOnly = !view.dataView[args.Row]["RowMod"].Equals("A");				
			}
		}

		if ((args.NotifyType == EpiTransaction.NotifyType.AddRow))
		{
			field1.IsEpiReadOnly = false;
		}
	}
1 Like

Thanks, Brandon. Interesting that you mention this, because I did do a trace when saving a record just yesterday, and thought that I might need to construct a BPM to handle it, but I never moved forward on that.

Looks like it falls within the Update method:

  <businessObject>Ice.Proxy.BO.UD11Impl</businessObject>
  <methodName>Update</methodName>

Thanks, Joshua.

I’ll give this a shot and see what transpires. I appreciate the follow-up very much and will let you know how things shake out.

big fat edit

It doesn’t look like this is working correctly with the row mod thing. I’m not sure what’s being seen where, but I don’t know if tying to the row mod thing is working.

So this is how you do it. Make a row rule with the wizard. Doesn’t really matter what it is because you are going to change it, but to make it easier, make it so Key1=Key1. After you save, the row rules, you’ll change the generated code to something like this. Noticed that I changed the field key1 to RowMod and the Equals to “A” (Like @jgiese.wci suggested)

   private void CreateRowRuleUD14Key1Equals()
   {
   	// Description: ReadOnlyHack
   	// **** begin autogenerated code ****
   	RuleAction[] ruleActions = new RuleAction[0];
   	// Create RowRule and add to the EpiDataView.
   	// Dummy Context Object
   	object contextObject = null;
   	RowRule rrCreateRowRuleUD14Key1Equals = new RowRule("UD14.RowMod", RuleCondition.Equals, "A", new RowRuleActionDelegate2(this.UD14Key1EqualsUD14Key1_CustomRuleAction), contextObject);
   	((EpiDataView)(this.oTrans.EpiDataViews["UD14"])).AddRowRule(rrCreateRowRuleUD14Key1Equals);
   	// **** end autogenerated code ****
   }

After you change that save close and come back (I think you have to do that), the row rules should look like this in the properties.

There is another block of code that was generated with the wizard and it looks like this. You can put whatever you want in that section and it will fire when your row rule fires.

	private void UD14Key1EqualsUD14Key1_CustomRuleAction(Ice.Lib.ExtendedProps.RowRuleDelegateArgs args)
	{
		// ** RowRuleDelegateArgs Properties: args.Arg1, args.Arg2, args.Context, args.Row
		// ** put custom Rule Action logic here
		
		epiShapeC1.Enabled = Key1Field.ReadOnly;
	}

I grabbed the control for the key1 field. (I’ll assume you know how to do that)

EpiTextBox Key1Field;
		Key1Field = (EpiTextBox)csm.GetNativeControlReference("46567b2e-6bc0-4967-be35-a0ec6843838f");

So now you can use the ReadOnly property from the key1 control and set those to whatever controls you want to set them equal to.

Use IsEpiReadOnly not ReadOnly.

I would go with the EpiViewNotification. The Row Rules (as I have them anyways) don’t seem to fire when you would expect them to.