Edit Grid applydata clarification

[llarge]

Hello,
I'm trying to get applyData response in my edit grid program working but it's giving me a little trouble. As far as I understand it, that proc should let me set the value of other fields that are in the same row of the edited field my user is changing. Hopefully, I'm understanding that correctly.
Here is what I'm working with. Here is the edit grid and the arrow is pointing to the value that gets changed. This is set up for cell editing.

image.png
In my helper program, I take that Gross Amount and then calculate the Discount amount and Net amount that are next to it. Once I have those values, here is the code that I thought would work.
I even converted the variables to UCS2

SetResponse('applyData':'APDISCOUNT':GLdiscountAmo untUCS);
SetResponse('applyData':'APNET':GLnetAmountUCS);?

I'm doing this in the ProcessEdit Proc.

My next step was to try to use SQL to insert those values myself, but I thought I could use this procedure. Am I doing anything wrong here? Any help would be great.
Thanks. ?

[llarge]

Update, I was able to get the behavior I was looking for but I have to use SetValue proc.

SetValue('APNINVGLDL':'DiscountAmount':%CHAR(GLDis AmountMoney));
SetValue('APNINVGLDL':'NetAmount':%CHAR(GLNetAmoun tMoney));

The next part that is a little confusing is that to get those values to show, I have to use an appvar that is linked to the grid in the refresh widget property. If I set that app var, the widget refreshes with these new values. I tried SetResponse('refresh':'true'); but that didn't. I noticed that the comment for that says"Refresh the contents of the grid (inline cell editing will ignore this)"? so I'm not sure if that's the reason why it's not refreshing.
The problem I have with the refresh now is that when my user tabs to the line description field which would be next, the helper program kicks off, does the calculation, and then since the grid is refreshed, the cursor loses focus on the line description field. I don't see a way in the helper program to set field focus as I could with a form helper.
What do you guys think?

[llarge]

ok, next update and questions. At this time, I have it working and behaving the way I would expect. The clarification I could use to help and could help others is this,
When do you use these built-in procs?
This I feel is the more confusing part of using the edit grid. There are 2 runs of this program in my application that I am seeing, the first run is inMode = EDIT. The next one is inMode = POSTEDIT.
During the EDIT mode, I do some calculations for the other fields. I have found that I need to do the setResponse('applyData') get get these values to show on the grid, but those values are not updated to the file. I then run SetValue to update these fields in the file itself. I also do not have anything for the value that was edited. It automatically gets updated in the file.
The POSTEDIT proc then gets run and I can make some changes to other widgets I have in my app that show status and these calculation totals.
Another thing that was causing me some confusion was the lack of logs.
In Portal Admin, I use the logs app quite a bit to see what's going on with the app. There is no listing of my program getting called. I can see my button helper and my form helper, but I have yet to see the grid helper app. I do see VVDATASRC get called with the action of "update record". That is where I'm able to confirm the extra values I'm trying to update in my field when my user is doing the cell edit. Is there a reason that the edit grid helper is not in the logs?
Thanks.

[Johnny Major]

When editing cells, I wouldn't refresh the widget, as that would cause the issue you're describing when users update cells and tab to the next editable cell.

First, some questions: did you ever get applyData to work on the helper program when they were editing the cell? For example, you should be able to set columns in the ProcessPostEdit by simply doing something like this:

dcl-proc ProcessPostEdit;

  SetResponse('applyData':'CZIP':'7777');
  SetResponse('applyData':'CNAME':'Johnny Major');
  SetResponse('success':'true');

end-proc;

Regarding ProcessEdit and ProcessPostEdit:

• ProcessEdit: Used to perform edit checks and/or set field values before the edit "update" is performed.
• ProcessPostEdit: Used for any processes that need to be performed after the edit "update" is successful, such as applying data, which sounds like what you're trying to accomplish.

For the call log, the only call you should see is for VVDATASRC with an action of updateRec. The backend will then call the validation program if one is defined. Whatever the helper program responds with will be in the response for the updateRec. I do agree the only way you would know it was the helper program assigned to the edit grid would be in the request of the call with the name of the program in the valPgm parameter. We will update the new NAB developer tool to show the information easily for edit grid validation program(s).?

[llarge]

Good morning Johnny, I removed the refresh once I was able to get these values I'm working with to show. The way I believe I got it to work is by using SetResponse('applyData') to get the values to show up on the grid, and then SetValue to get the same value to be updated in the file. I have been trying so many different combinations of procs in both the ProcessEdit and the ProcessPostEdit to get a better understanding of what's going on with the backend. What I find really interesting is the value that is edited in my grid, I don't have to applyData with that one. It gets applied no matter what. I'm assuming since it is a large numeric value(it's a dollar amount), I haven't had to deal with any errors yet, that is the next thing I need to work on. I have been focusing on getting it to work first.
So to clarify, applyData only sets the values in the grid and displays them for my users and not in the file. setValue will put those values in the update statement that runs with VVDATASRC but will not show them in the grid. At least that is what I'm experiencing. I'm also doing these calls in the ProcessEdit proc, do you think it will be different if I did them in ProcessPostEdit?

Update: I just tested my last question and I'm experiencing the same behavior I was explaining before. applyData sets values in the grid, but does not update the file. This is from the logs.
image.png?Here you can see the response from the backend program. There is the applyData response.
image.png?Here is the update statement missing those values. They show up in the grid but are not in the file.
Here is what the grid looks like.
image.png?

[sean.lanktree]

"applyData" is only used for the front-end to update the values on the UI. SetValue will update the values in the database (assuming your grid is not set to use local data) but only if called during the "ProcessEdit/Add" . "ProcessPostEdit/Add" is called after the DB update/insert.

[llarge]

Hello Sean, I have figured this out now. I think the trouble I was having was the best description for these procedures I could find was in the comments of the program. There is no information about which helper proc should be used or not used in different ProcessProcs. It's also a little unclear that the applyData only updates the UI and not the file. The first couple of times I read it, I thought it would apply the data to the file as well as the grid.
After working on this for the last couple of days, I was able to get it to do what I needed it to. Is there anywhere else I could get some more information on these helper processes besides the comments of the helper program?

[robert.swanson]

We are currently in the process of updating the Valence and NAB documentation across the board, NAB in particular as the pace of development has been on quite a tear lately. Expect to see that update in the next couple months.

As for the NAB exit/helper programs, all of the most pertinent info is currently in the source code comments, but we will soon have a dedicated section in the documentation for each of those programs, with more detailed information where appropriate.