"WAIT" command?!

Hello,

I am a bloody rookie in Cobol and my program is not very well written,
otherwise I would not have that problem I guess..
Is there something like a "WAIT" command?
at the moment, after a special event, the program stops, because it has
reached the end of the program code.
but it should just wait for the next user interaction. Do you know how I can
do this?

thanks a lot!

dennis

Dennis Dahn wrote:

> Hello,
>
> I am a bloody rookie in Cobol and my program is not very well written,
> otherwise I would not have that problem I guess..
> Is there something like a "WAIT" command?
> at the moment, after a special event, the program stops, because it has
> reached the end of the program code.
> but it should just wait for the next user interaction. Do you know how I
> can do this?
>

Hmmm...

Maybe ACCEPT?
http://www.csis.ul.ie/COBOL/examples/Accept/ACCEPT.htm

"Andreas Hentschel" <andr2001@gmx.de> schrieb im Newsbeitrag
news:81d1$45e1cb99$d9bca24b$2331@nf18.news-service.com...
....
>
> Maybe ACCEPT?
> http://www.csis.ul.ie/COBOL/examples/Accept/ACCEPT.htm
>

Well, maybe I have to be more specific. I have a GRID, and I want to
evaluate the inputs. So after some code lines the evaluation is over and the
program should wait until the next insertion in the GRID. but if I use
ACCEPT the event-handler for the cell does not start anymore, the program
stops because it is the end of the code. how can i make it that the
event-handler is called again?

That sounds like Acucobol - is it?

Generally you have your grid in a screen section entry and you use a PERFORM
UNTIL loop to continually accept the screen until some event occurs where
you want to exit the program.  After your event handler code ends, the
screen gets accepted again so the program doesn't end.  It's a way of
simulating event driven code within Cobol.

You'd have to post an example of your code for anything more specific or
look at the sample grid program(s) that come with the compiler.


"Dennis Dahn" <DDahn@web.de> wrote in message
 news:45e1ce76$0$20293$9b4e6d93@newsspool
3.arcor-online.net...
>
> "Andreas Hentschel" <andr2001@gmx.de> schrieb im Newsbeitrag
> news:81d1$45e1cb99$d9bca24b$2331@nf18.news-service.com...
> .... 
>
> Well, maybe I have to be more specific. I have a GRID, and I want to
> evaluate the inputs. So after some code lines the evaluation is over and
> the program should wait until the next insertion in the GRID. but if I use
> ACCEPT the event-handler for the cell does not start anymore, the program
> stops because it is the end of the code. how can i make it that the
> event-handler is called again?
>

Cheers guys, it works fine now :-)

Dennis

"JJ" <jj@nospam.com> schrieb im Newsbeitrag
 news:dfydnVHGl4oRcXzYnZ2dnUVZ_qGjnZ2d@co
mcast.com...
> That sounds like Acucobol - is it?


yes it is


> Generally you have your grid in a screen section entry and you use a
> PERFORM UNTIL loop to continually accept the screen until some event
> occurs where you want to exit the program.  After your event handler code
> ends, the screen gets accepted again so the program doesn't end.  It's a
> way of simulating event driven code within Cobol.

but which event should i use in the perform loop?
i have a grid and some buttons, so if i use something like

perform until ende = 1
accept Screen1
end-perform


then it does not accept the button-click event. so the loop should end and
go the according event-
button click -> go to button click event
entry in grid -> according event

Dennis Dahn ha scritto:

> "JJ" <jj@nospam.com> schrieb im Newsbeitrag
>  news:dfydnVHGl4oRcXzYnZ2dnUVZ_qGjnZ2d@co
mcast.com... 
>
>
> yes it is
>
> 
>
> but which event should i use in the perform loop?
> i have a grid and some buttons, so if i use something like
>
> perform until ende = 1
>            accept Screen1
> end-perform
>
>
> then it does not accept the button-click event. so the loop should end and
> go the according event-
> button click -> go to button click event
> entry in grid -> according event

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
event-procedure.
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
END-ACCEPT
End-Perform

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

"Dennis Dahn" <DDahn@web.de> wrote in message
 news:45ea0187$0$6404$9b4e6d93@newsspool2
.arcor-online.net...
> 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
> event-procedure.

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
>    END-ACCEPT
>  End-Perform
>
> 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
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
screen.

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
occurs?

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

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 :-)

Pete.

....
Hello Pete,

thanks a lot for your detailed answer!
Mmmh, but I still have not found the error, but maybe it is very simple and
probably my poor knowledge is the cause for all this.

one example: I have an event  like:

cell-in-grid-clicked-event.
perform xyz.


xyz.
go to abc.

If I have this "go to abc", is the the return to
"cell-in-grid-clicked-event" lost in the stack?


thanks a lot again!!