Re: Stategy for (Large?) 16bit COBOL code conversion to Net Express


HeyBub <heybubNOSPAM@xxxxxxxxx> wrote in message
news:13ha8ris55j51ee@xxxxxxxxxxxxxxxxxxxxx
tlmfru wrote:
HeyBub <heybubNOSPAM@xxxxxxxxx> wrote in message
news:13h9c4vc165qvc2@xxxxxxxxxxxxxxxxxxxxx


3. The logic of your programs will change. Many events will be
occuring simultaneously (updating a file, mouse movements, button
pushes...) all coming in at random times and you'll have to re-think
your logic from sequential processing to event-driven control. Once
you get past the barrier, it's automatic, BUT a straight sequential
processing stream can get terribly confused when the user taps the
"Pause" button.



You know, this is something of a programming "urban myth".
Event-oriented programming isn't something absolutely and
"if-and-only-if" associated with GUI programming. If "News"'s
systems are screen-driven then he's doing event-oriented (EO)
already. Even if you have only the display & accept verbs available
you can do a crude rendition of EO. All that's needed is to write
your program so as to assume something independent to handle the
screen-io functions (which all modern Cobol implementations provide);
pass on a message or a screen to the handler, set switches so you
know where you were and what you were doing in the program, then wait
for something to come back. Your programming action will then depend
on what you get and what switches were set. You certainly CAN
program so as to have events happen in a strict sequence in this
environment - but so can you in any GUI environment.

It's not an urban myth. It's not even a programming myth. In a screen full
of controls, when one is selected, that's an "event." Another event may be
selected that modifies the first event.


<snip>

Say:
Exiting a field triggers data evaluation logic. Meanwhile, the cursor
proceeds to the next field. The data validation logic on the first field
detects and error and informs the user. After the user acknowledges the
error condition, focus is returned to the first field. This triggers a
lost
focus event on the second field which triggers the data validation logic
for
the second field and so on...

Unless the programmer knows how these events are being aligned, much hair
will be pulled.

There's dozens of these "gotchas" that batch programmers, even CICS
programmers, are not familiar with.

As to an example of PAUSE being used in a data-entry screen, how about a
look-up feature that finds millions of records?



No, no, Hey, you're missing my point. I'm quite aware of this and other
situations and have gone along with the "best practice" rules whether I
liked them or not. (My absolute non-favourite was that enabling a field in
one GUI environment would generate a lost-focus event for ALL previous
buttons, fields, etc., on the screen). I was trying to demonstrate that
"event-oriented" and "GUI" are not the same thing, and that you don't
require the latter to do the former.

If the lookup finds millions of records - well, every one I've ever worked
with had a maximum number that it would display at once - and had a cancel
button.

PL


.