E9.2 Can we force Grid Record record is exited Changed Inline

[JohnDanter2]

Hi folks

I have an issue whereby I want to force my E1 screen to execute Grid Record record is exited Changed Inline even if a user has not changed anything.
I have a screen that validates input data and shows errors. Any errors disable/hide the OK button until they are gone (controlled by a flag)

The users can fix the errors by changing data and try again or click delete to remove the GC line (removing all errors)
I dont' want to write code to loop through the grid as there will be too many records, I just want the screen to run at least one grid row exited event to force the flag to clear and check all is ok.

So any idea how to do this please?

Thanks

John

 

[Larry_Jones]

John
How I would accomplish what you want is to move your code from the grid row exited event into a hidden push button.
Call the push button from grid row exited and wherever else you need to invoke it.

 

[JohnDanter2]

Now why didn't I think of that

Excellent idea sir

 

[BOster]

John
How I would accomplish what you want is to move your code from the grid row exited event into a hidden push button.
Call the push button from grid row exited and wherever else you need to invoke it.

That definitely fits the code reuse design pattern and makes it much easier to organize and refactor code. I do this A LOT (basically use push buttons as sub-routines) with form level type events and have done this with Grid events in the past like Larry advises. One word of caution on calling push buttons in grid events, it can cause any errors thrown by BSFNs in the button to not be bound to any specific grid cell but will just kind of be "floating" form level type errors not bound to any control or grid cell. This can be confusing for the user and make it hard to clear either through code or when the BSFN is re-called. I have always wished Oracle would change this so you could move BSFNs from the grid row event to a button called by the grid row event and have them behave the same way - again form form level type events they do.

 

[JohnDanter2]

That definitely fits the code reuse design pattern and makes it much easier to organize and refactor code. I do this A LOT (basically use push buttons as sub-routines) with form level type events and have done this with Grid events in the past like Larry advises. One word of caution on calling push buttons in grid events, it can cause any errors thrown by BSFNs in the button to not be bound to any specific grid cell but will just kind of be "floating" form level type errors not bound to any control or grid cell. This can be confusing for the user and make it hard to clear either through code or when the BSFN is re-called. I have always wished Oracle would change this so you could move BSFNs from the grid row event to a button called by the grid row event and have them behave the same way - again form form level type events they do.

Yeah that would be my only issue too, which GC row am I on at the time I click a button as I'd be on none really. So I'd have to force/save the GC row #

 

[BOster]

Yeah that would be my only issue too, which GC row am I on at the time I click a button as I'd be on none really. So I'd have to force/save the GC row #

It's not so much that the code in the Push Button doesn't know which GC to work with, that can easily be solved, in fact in most cases the code in the push button called from the grid event can literally be the same code that would be in the grid event itself. The only real downside I have ever encountered is the whole error thing I described above.