Re: "WAIT" command?!




"Dennis Dahn" <DDahn@xxxxxx> wrote in message
news:45ea0187$0$6404$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.





.



Relevant Pages

  • Re: How to fire an event
    ... I have an Infragistic datagrid control, ... The button click event is being raised upon a post-back to the server. ... manipulating the grid in script would cause a server event to be raised. ... The problem here is that I have no idea whether the grid will raise the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: need graphic suggestion
    ... Labels have all the functionality and control needed. ... this grid control many years with great success. ... default scroll bar that's an option for any window made in windows. ...
    (microsoft.public.vb.general.discussion)
  • Re: wide screen text mode?
    ... Is there a reason it *must* be DOS text mode? ... attribute color control. ... With a script or a long novel, each character can be assigned a custom ... pasted 4 such screens together to get a screen that is 1212x800. ...
    (comp.os.msdos.programmer)
  • Re: Most popular object persistence framework
    ... No offence to Exceed in particular, but control vendors don't always ... products you can use with exceed's data grid currently without adding ... I see that infragistics is now shipping their WPF ... products and support for proper and full WPF binding? ...
    (microsoft.public.dotnet.framework)
  • Re: Error 424 : object required : cant refer to property of Active-X control in DHTML project
    ... my purpose is to have the VSFlexgrid running within a webs site since I ... find out how I can transfer an ADO recordset out of an ASP -page to a HTML ... page on which the grid resides. ... > General Tools Control box are all disabled. ...
    (microsoft.public.vb.controls.internet)