Re: "WAIT" command?!

"Dennis Dahn" <DDahn@xxxxxx> wrote in message
Unfortunately my problem still has not been solved, so I ask again for
your help.

I am working with Acucobol, and after one grid-event I have a lot of code
to execute. If I use 'PERFORM "procedure-name"' I get a perform stack
overflow, because there are a lot of PERFORM-calls. So I used GO TO in the

Ouch! Have you tried increasing the stack size?

The problem is that, after executing the code, the program exits.

I tried a lot, for example:

perform until Exit-Pushed
ACCEPT Screen1
ON EXCEPTION PERFORM Acu-Screen1-Evaluate-Func

with this one the buttons on the screen work well, but the grid and the
defined events for the grid don't work anymore.
Has anybody an idea?

Thanks a lot!

Dennis, I'd like to help here as I have extensive experience with event
drivern programming in COBOL, but I am not familiar with AcuCOBOL.
Therefore, I may be way off the beam with the following. (I'm posting it
anyway because it may trigger sanother idea for you...)

From your posts, a couple of observations spring to mind...

1. ACCEPTing a screen is not the same as activating the events for a control
on it. I believe there may be some confusion between these two things. If
you want the data from your grid control so you can validate it, that will
occur independently of the screen ACCEPT. (At least it does in every COBOL
environment I have used... Not sure about AcuCOBOL. It is possible the
events are queued until you do the ACCEPT, but that seems unlikely...)

The whole point about event driven programming is that you cannot control it
with ACCEPT as you might in standard COBOL. You display your grid and when
the events you have "expressed interest" in occur, your event processing
code is activated. It is completely independent of your ACCEPT for the

Is it possible that your event processing is terminated because you have
ACCEPTed the screen?

2. What would happen if you ACCEPT the screen when the Exit-pushed event

Some observations about the event driven model (may not apply to

1. Screens are treated like forms and the controls on them raise events.
You should be able to detect button presses (with Click or keyUp/KeyDown
events) and if you are using ActiveX controls like grids, the events raised
by the control will be detectable also.

2. You CANNOT ( and shouldn't want to) control when and how events are
raised. This is a major departure from "normal" COBOL where all I/O is
controlled by the program using READ or ACCEPT. The event driven model is
controlled by the Windows message loop (usually invisible to COBOL) which
does the "polling" of open windows to see what events they have raised and
pass those events to the code that is "interested" in them.

3. If you use ACCEPT and DISPLAY with a defined screen section, this is NOT
using the Windows event model. I wouldn't expect your grid to work correctly
in this environment, UNLESS you can find a way to "defer" the end of the
event cycle until you are satisfied that everything on your screen has been
processed. You might do this by detecting that the Exit button or OK button
was clicked and so it is then safe to start processing. (maybe close the
window and/or display another processing-related one...) If you are using a
grid, you might detect when all cells in the grid have been used, or
whatever, the point is that each cell in the grid can raise its own events
(like, "I've lost focus" or "Enter was pushed while the focus is on me")

Have another look at your AcuCOBOL docs regarding how event processing is
handled. See if there is a sample app. Try and establish how event
processing is cycled in the AcuCOBOL environment.

The main thing to remember is that for a control like a grid, you CANNOT
control when and how events are raised, all you can do is respond to them.
It seems that something in your environment is terminating the event
processing and the prime suspect to me is your ACCEPT.

Sorry if this is no help :-)