Browse Lookup Message (Scott Walker)

[Richard Kreiss]

Jose,

Many of us did this years ago before the browse lookup was available.  If I
recall, there was a routine called "zoom" but it did not use arrays.  We
filled a screen with dummy fields and then used getnext or getprev to allow
scrolling.  

The only reason I can think of to use arrays or the old "zoom" method is if
one needed to set up a timing routine to reread the data and the update the
screen with the changed data.  

That is the one problem with a browse lookup.  Without user intervention,
the data viewed is static.  I would love to see one more variable added to
the browse structure, something like a tim="5000", "timeit",  The first
value would be how long an interval(milliseconds) and the second the
subroutine to execute at the start of the interval.  That is where the
programmer controls the action.  There could be a timer there and after so
much time with nothing happening, the browse could be closed.  If there was
an intervening action, the clock could be reset.  Of course if your using
arrays, one can do this.

See more comments below.


> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Jose
Lerebours
> via Filepro-list
> Sent: Thursday, March 17, 2016 1:04 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: Browse Lookup Message (Scott Walker)
> 
> IMNSHO,
> 
> The use of the browse lookup is nothing but a lazy developer solution.
> 
> Use arrays and routines to populate and solve the browse lookup issues -
You
> may write 60 to 100 lines of code once and BANG!, you have the code which
> can be used genetically and universally with no or little change.
> 
> Granted, 1 to 5 lines of codes are much easier and faster to write than
> 60 to 100 but the added benefits makes it all worth your while.
> 
> I have been using this as far back as I can remember and I rarely ever use
> browse lookup where data control, management, editing, sorting, filtering,
> posting ... is needed.  Yeah, "drop" came about after I had written array
based
> browse mechanism and yet, I never gave it up.
> 
> So, the use of arrays + waitkey is the best solution you can entertain to
take
> absolute control of your 'browse' lookups ... Heck, I even had a few
instances
> where I allowed left/right scroll which you cannot do in filePro lookup
(or at
> least last I checked).
> 
> Some of the benefits:
> (a) Depth control - a single line can be as many rows as you want


> (b) Scroll up/down, left/right ...
Can do that currently, John Esak worked out the programming to do this with
the current browse function

> (c) Capture function keys or any key "waitkey" can read
Can do this with @bk and @sk currently - don't need waitkey

> (d) Added control on screen content as user scrolls from row to row
Again, have this ability with programming available 

> (e) Ability to fetch info prior to placing bar over row
Can do this with the prc= option.  Prior to each record being displayed,
this routine runs.  

> (f) In place edit by combining with "input" and "input popup" commands
Can do this now. Grab the record number, using in input popup of a screen
with dummy fields, and use @br and some math to place the "screen" over the
browse record to be updated. When the screen is saved, loop to a record #
lookup, post the data and loop back and re-execute the browse.  You are at
the same place and the record has been updated.  I do this with a lot of
browse lookup where I need in place editing of a record.  Makes it look like
the line is actually being edited in the browse. (Many will say that the
update info can just be posted without a record # lookup.  I find that this
technique insures that the data gets to the proper record especially if
thelookup key is the same for all the records)

> (g) Gives user ability to jump a number of pages at once (paging)
> (h) Since all data is in an array, export to excel or pdf is half way done
...
See above prc= option could handle the export directly if the record isn't
going to be dropped. 

One could also use xkey= option which could allow for exporting just the
line or lines selected if not done automatically.

> (i) Since you're using waitkey or inkey, you can run additional process in
> between key strokes
> (j) ... need I say more?

With some thought, many of the activities you mention can be done from
within the browse routine.  It's not perfect but it fits almost 99% of most
developer's needs.

Richard Kreiss
GCCConsulting

> 
> Kind of sticking my neck out here - Now let that guy that usually talks
smack
> and knows nothing about programming get involved!
> 
> 
> 
> 
> 
> On 03/17/2016 10:43 AM, Kenneth Brody via Filepro-list wrote:
> > On 3/17/2016 9:25 AM, Jason Garner via Filepro-list wrote:
> >> Good Morning Scott,
> >>
> >> I am new to FP programming but in Linux FP you can use a "-S"
> >> argument that
> >> will get rid of that message and the user will just stare at a blank
> >> lookup.
> >>
> >> I am not sure if this is the same for Windows FP.
> > [...]
> >
> > With very few exceptions, such as SYSTEM (which, by its very nature,
> > is system-dependent), and USER (pre-5.7), filePro processing is
> > virtually identical between *nix and Windows.
> >
> > The same "-s" flag is available on all filePro platforms.
> >
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list