Headerless Detail clearing GC Errors on previous lines

List,

I have a custom headerless detail with column GC_AN8, GC_MCU, and GC_UDC_EDIT.

GC_UDC_EDIT must be a valid entry in a particular UDC
AND it must valid for specific rules regarding GC_AN8 and GC_MCU.

As this error checking needs to perform when any of the three columns is exited and changed,
I have the code in a pushbutton.

There are no enabled "Clear Grid Cell Errors" for any of the columns on the grid, anywhere in the form's ER.

When Row_1 GC_UDC_EDIT is in error, leaving the row retains the error as it should.

When I enter ROW_2, the error still displays on ROW_1.
As soon as the "Press Pushbutton" is executed for ROW_2, the error on ROW_1 is cleared.
This is true if I'm going from ROW_2 to ROW_3, etc.

I've used the GC OVERRIDES to disable editing on GC_UDC_EDIT, I've removed the fact that GC_UDC_EDIT is a mandatory entry, but the previous line's error still clears.

I'm stumped as to why the prior row's error is cleared.
Any relevant thoughts and/or suggestions are welcome.

Not exactly sure of your how your code is implemented and it might be any number of things, but if you are calling code in a button via the system function pushbutton that is triggered by a grid event, you may want to move the code from the pushbutton directly into the grid event. I have sometimes had problems with the Grid/BSFN error mechanism if I don't call BSFNs that have GC variables passed into them and subsequently set errors on the grid cells if I don't call the BSFN directly from the grid event(s). Having to do this is a pain as it results in harder to maintain code but I have found that it simply works better with the BSFN error/APPL Grid control integration. Does that make any sense?

Brian,

"Remove the pushbutton" wasn't the answer it wanted, however it is an answer that worked.
I put the code into the three grid columns, removed the pushbutton, and the issue went away.

Thanks VERY much for a speedy, and correct, answer.
Gene

This is perfect analysis by Brian.
When you call push button from your grid event, the reference to the Grid row is lost and that causes the issue.

Use the code in grid event instead of Push button.

Glad it's working.
However you can also get around this by using the Get Grid Row (selected) system function.

But yes Brian is right, GC variables are for GC events only.

But....
We can also validate the grid in the OK button, but we must get the grid row count, loop for each grid row and set the focus with the system function mentioned above.

Get Grid Row
GetGridRow causes the specified row to be used for subsequent ER on the current event. If the row specified is greater than the total number of rows, the last row is used. If the row specified is invalid, the active row becomes zero.

In essence all it does it pretend to click the grid row for you

So from a grid event if I do the following:

<font class="small">Code:</font><hr /><pre>
Grid.Event
- GetSelectedGridRowNumber(nGridRow)
- PushButton(MyButton)
MyButton.ButtonClicked
- GetGridRow(nGridRow)
- MyBusinessFunction
-> GC_Var1
-> GC_Var2
-> ....
</pre><hr />

It will work the same as the following (with regards to errors thrown in MyBusinessFunction on passed GC Params):

<font class="small">Code:</font><hr /><pre>
Grid.Event
- MyBusinessFunction
-> GC_Var1
-> GC_Var2
-> ....
</pre><hr />

If so, that would be good to know. I often call MyBusinessFunction from multiple grid events and grid column events and it would be nice to be able to create a PushButton called Call_MyBusinessFunction so I only have to map the GC vars once. I do this for functions I call passing FC variables (header type info) and it really makes maintaining code easier and less error prone.