Re: "WAIT" command?!
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 9 Mar 2007 10:13:33 +1300
"Dennis Dahn" <DDahn@xxxxxx> wrote in message
news:45f02346$0$15946$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...OK, that looks fairly normal (apart from the go to abc :-))
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!!
You probably don't need to go to abc, if you are doing this to set up
another cell-clicked event. Each cell that is clicked will raise the click
event for the grid control.
Without seeing what abc does, it is difficult for me to give you advice, but
consider the following:
cell-in-grid-clicked-event section.
cig.
*>
*> This code is executed every time a cell on the grid is clicked.
*>
perform xyz
perform abc *> keep abc within the event "range" and ONLY execute
it here IF
*> it is part of the event processing.
.
cig-exit.
exit.
some-other-event section.
etc and so on...
I have sectioned this code simply to show the range of each event process,
but if you don't like sections, you don't need to do that. Use whatever
style you feel comfortable with; (Paragraphs are fine, but, for me, using
"section" makes it absolutely clear exactly what is associated with each
event).
When you set up your events and specify which events you are interested in
(not sure how and where you do that with AcuCOBOL) you need to specify for
the grid:
On Click event, perform cell-in-grid-clicked.
Don't worry about where control goes after that. (I think this may be the
cause of your problem). As I tried to explain in my previous post, event
processing is asynchronous. Handle the event and DON'T send control back to
abc. The underlying message loop keeps polling for events for you and
activates your event code when it finds something. The only time you need to
take action is when processing on that screen is finished, and that is
usually indicated by the user pressing Enter or OK. At this point you can do
any validations of fields you have collected, and execute the "business
layer" of your code. When that completes you will need to reactivate the
User Interface again, and you do that by sending another form or updating
(maybe clearing fields and displaying an error status, if errors were found)
or refreshng the same one.
Try not to worry about executing the "main loop" as you might in a normal
COBOL program. Simply specify the events you want and provide the code to
process each one. Keep this code encapsulated as much as possible.
Your "main loop" simply displays the form; after that, events occur and are
processed asynchronously. When the OK button is clicked THEN you may want to
go to abc :-)
Hope this helps,
Pete.
perform xyz.
xyz.
go to abc.
.
- References:
- Re: "WAIT" command?!
- From: Dennis Dahn
- Re: "WAIT" command?!
- From: Pete Dashwood
- Re: "WAIT" command?!
- From: Dennis Dahn
- Re: "WAIT" command?!
- Prev by Date: Re: FUNCTION's LOCALE-(DATE/TIME)
- Next by Date: Re: FUNCTION's LOCALE-(DATE/TIME)
- Previous by thread: Re: "WAIT" command?!
- Next by thread: FUNCTION's LOCALE-(DATE/TIME)
- Index(es):
Relevant Pages
|