Re: Report Writer
From: Richard (riplin_at_Azonic.co.nz)
Date: 10/23/04
- Previous message: Michael Mattias: "Re: WinAPI calls that use the Shell32.lib library"
- In reply to: Lueko Willms: "Re: Report Writer"
- Next in thread: William M. Klein: "Re: Report Writer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 23 Oct 2004 11:27:55 -0700
l.willms@jpberlin.de (Lueko Willms) wrote
> r> You do an ACCEPT and then check the results. This may indicate which
> r> key terminated the accept and where the cursor was positioned.
>
> That lacks quite some features then for using it on e.g. a Windows
> workstation.
There is no requirement, even in a Windows type system, for there to
be separate event handlers for different events. It is entirely
possible to have a single return point for all events as long as the
type and position of the event can be determined.
For example Flexus SP/2 'falls off the CALL' and has sufficient
information to determine where and how the event occurred. The action
blocks are put into EVALUATE statements rather than separate event
handlers.
In any case the X-Open screen section was specific to terminals of the
day and predated Macintosh, GEM and Windows.
> Using the REPORT WRITER, there is not much need to rewrite a
> printing program, because its all in the DATA DIVISION. REPORT WRITER
> is rather a program _generator,_ which needs some configuration.
... by the PROGRAMMER.
While the programmer may not be changing the procedure division he is
still changing source code and recompiling. In many environments that
requires scheduling, retesting and release processes.
> BTW, it is not limited to "reporting programs", and as I said, and
> for "reporting programs", I would suggest an alternative:
> I suggest to look up the data online and interactively in the
> database, and not print so many reports.
Exactly. They don't want to wait for the programmer.
> BTW, have you ever used REPORT WRITER?
No. I evaluated using it, I understand entirely what it does, but I
had written my own dictionary based reporting and data extract
programs that were driven by text report specifications and could be
set up and used by users to get at their data. If they didn't want to
do it them selves then I could dial into their machine and set up the
report in a few minutes.
The thing about RW is that it is a solution. If it fits the problem
exactly then it is the best solution, if it doesn't quite fit then it
may be the worst. The problem that it best fits is: printing a report
with page breaks and control breaks from a primary file.
If the system has been designed with the use of RW as a target then RW
is the perfect fit for all manner of things.
However, I design systems around other needs and with other
requirements in mind (such as the mechanisms that I have developed)
and RW just doesn't fit.
I can quite understand your enthusiasm for it and the frustration at
not convincing others that it is a really good thing, but it is of no
use to _me_ at all.
- Previous message: Michael Mattias: "Re: WinAPI calls that use the Shell32.lib library"
- In reply to: Lueko Willms: "Re: Report Writer"
- Next in thread: William M. Klein: "Re: Report Writer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|