Disappearing data on screen

How do you keep input data from disappearing from the screen from one
display to
the next? I'm using Fujitsu COBOL 5.0. Thanks.

"Colonel_Buck" <bkeith@alumni.utexas.net> wrote in message
news:1118012259.831407.79890@g43g2000cwa.googlegroups.com...
> How do you keep input data from disappearing from the screen from one
> display to
> the next? I'm using Fujitsu COBOL 5.0. Thanks.
>
Code 'USING' instead of 'FROM' .

Pete

Pete Dashwood wrote:
> "Colonel_Buck" <bkeith@alumni.utexas.net> wrote in message
> news:1118012259.831407.79890@g43g2000cwa.googlegroups.com... 
> Code 'USING' instead of 'FROM' .
>
> Pete

Pete Dashwood wrote:
> "Colonel_Buck" <bkeith@alumni.utexas.net> wrote in message
> news:1118012259.831407.79890@g43g2000cwa.googlegroups.com... 
> Code 'USING' instead of 'FROM' .
>
> Pete
Works perfect! Thanks. I wonder why the TO and the FROM don't work
together???

"Colonel_Buck" <bkeith@alumni.utexas.net> wrote in message
news:1118089192.398974.77920@g44g2000cwa.googlegroups.com...
>
>
> Pete Dashwood wrote: 
> Works perfect! Thanks. I wonder why the TO and the FROM don't work
> together???
>
>

Sorry for previous blank post...finger trouble.

See below...

"Colonel_Buck" <bkeith@alumni.utexas.net> wrote in message
news:1118089192.398974.77920@g44g2000cwa.googlegroups.com...
>
>
> Pete Dashwood wrote: 
> Works perfect! Thanks. I wonder why the TO and the FROM don't work
> together???
>
You have missed the point of these constructs. (I don't blame you because
the concepts are not even mentioned in the manual).

TO allows you to protect fields so that they become 'read only'.  It is
intended to emulate devices in mainframe environments that have attributes
to do this (like IBM 3270).

Having decided that your field will be 'read only', it would be a
contradiction to then place output data in it. So FROM cannot work with TO.

In the same way, an output only field can be defined with FROM, and, in the
same way it will be incompatible with TO.(If the field is defined for output
only, you cannot accept input from it.)

USING allows both input and output of the field, as you have seen.

SUMMARY:
You may find it helpful to think of these constructs in the following way:

TO = input only. Will not be refreshed after data is collected from it.
FROM = output only. Will not allow input of data in the same field. The
field is refreshed when redisplayed.
USING = input/output. Allows data collection and can be updated. The field
is refreshed with its current contents on subsequent displays.

ADVICE: (Opinion that is arguable, but I have no intention of arguing it;
make up your own mind.)

Screen sections in COBOL, particularly in Client/Server environments, are an
obsolete cop out for people who can't deal with event driven GUI
programming, and are hanging desperately to the command line interface
because 'we've always done it that way'. COBOL programmers tend to think in
terms of procedural programming and are used to controlling the process, so
ACCEPT and DISPLAY is simple and familiar.

Get into event driven programming; it is fun and satisfying.

You have a superb environment for developing  'quick build' GUI
applications: PowerCOBOL. (It comes with Fujitsu NetCOBOL version 5).

Do the PowerCOBOL tutorial. You won't be sorry.

Pete.

OK Pete, you shamed me into looking at the PowerCOBOL Getting Started
book. The problem is that all of my experience with business
applications have dealt with only 4 different data types; character,
numeric, date and time.

I just don't see the up-side of a real-life business application
having bunny rabbits hop across the screen. Don't get me wrong, it's
nice that it can be done, but I don't see where it might fit in with
applications that I'm designing, building and testing.

Have you any examples of a PowerCOBOL application written for a bank,
or insurance company, or hospital, etc.....?

If I could take a look at one of those, I could see how one is put
together, how the forms work and feed each other, how the data flows,
logic, etc.....

Thanks, blk...

In article <1118462797.976806.84850@g14g2000cwa.googlegroups.com>,
Colonel_Buck <bkeith@alumni.utexas.net> wrote:

[snip]

> I just don't see the up-side of a real-life business application
>having bunny rabbits hop across the screen. Don't get me wrong, it's
>nice that it can be done, but I don't see where it might fit in with
>applications that I'm designing, building and testing.

Hmmmmm... reminds me, long ago, of a memo I was forced to write comparing
an IBM mainframe and an IBM PC - this must have been in the mid-late 1980s
or so - that had, as its target readership, a fellow who was known for
blustering 'A mainframe can do anything a PC can do!'

It contained the immortal line of 'Mainframe and PCs are rather different
in their processing focus and application capabilities; this might be why
one rarely sees a flying-toaster screensaver on a 3270 terminal.'

DD