browse lookup in report

[John Esak]

> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] On Behalf Of Enrique Arredondo
> Sent: Friday, December 11, 2009 2:32 PM
> To: filepro-list at lists.celestial.com
> Subject: browse lookup in report
> 
> Why can't we use browse lookups at the selection processing 
> of a report ?
> 
> Is there a scientific explanation for that?
> 
> thanks
> 
> EA

Yes, the answer is. Just because. 

Now this worked when my sister used it on me back in the 50'.  Has it lost
its power?

John Esak

P.S. There really is probably no technical reason why the browse function
couldn't be adapted to work without the concept of a screen behind it.  The
larger issue is that a browse by its nature is a mechanism that allows the
user to select one (1) record. You would have to arrange some "other"
processing simply to hold any records (more than one) on which you were
going to run the report part of the whole routine.  There are numerous ways
of doing this of course... None really perfectly suited, but some ideas do
come to mind as work-arounds.  Sit in rclerk and run your browse against the
file from which you want to select records.  Store them in another file
congruent to the first file and then ump out with a SYSTEM command to
actually run the report on that spin-off file.

Another really off-the-top with no sanity checking at all that would run in
select processing is:

Put up an array (you know a listbx) of the file you are sitting in.
Selecting a choice from the listbox would lookup dash you to that record and
select it, then put up the array again.  When they were done picking
records, lookup dash to the last record in the file (based on the command
line choice of an index) and END.  The report would then run with all the
choices made through the listbox method.  Very strange, but I don't see why
it wouldn't work.

John