Browse Lookups

Tue Jun 26 10:39:46 PDT 2018

Richard:  "Problem with your not tried suggestion is that the browse 
lookup occurs outside the normal processing and will not see anything 
done outside the browse that’s why the @bk option. "

Actually, I do accommodate for that in my second suggestion - via the 
pushkey command (and have now since tested such and it works as 
expected).  (Note to reader - Richard's reply here did not include my 
suggestions - refer to the separate reply to Scott to see my second 
suggestion.)

But something else you wrote, Richard, reminded me that filepro shows 
results in the browse when it has enough to show, so my second 
suggestion would only help the user while they are waiting for the first 
set of browse results to appear.  It doesn't help for the process wait 
time that occurs when the user pages down in the results which could be 
significant in Scott's case.

Because of Scott's data circumstance and the limitations mentioned 
above, I would recommend the first solution I suggested. As the end-user 
I would prefer one wait period (with status notice or progress bar) that 
ultimately results in all desired results being  shown from a temporary 
file and where page up/down wait time is eliminated.  (Rather than 
adding time via browse processing  to each instance where the user pages 
up or down and where there may already be significant wait time because 
filepro could be constantly churning past large numbers of records that 
are not part of the desired selection.)

This was my solution #1:

-get the current process ID - remove records using this key from a new 
temp file (small loop just in case the last step failed at one time)

-put up a message 'building' (or start progress bar)

-build the desired results into the temp file - keyed by the current 
process ID (to avoid conflicting with another user)
   (update progress bar as this is built)

- take down your message/progress bar

- browse ALL records in the temporary file

-when the user exits the browse, remove the temporary records that they 
created in the temp file

Of course this method then required that any actions that are to take 
place against the detail file being browsed need to do so starting with 
the selected *temp file record* as a reference.

Also note that such a temp file could just be a qualified key of the 
detail file - you would just need to add the field for the process ID.

--Bruce

On 6/26/18 11:38 AM, Richard Kreiss wrote:
> Problem with your not tried suggestion is that the browse lookup occurs outside the normal processing and will not see anything done outside the browse that’s why the @bk option.
>
> I would love to be able to set a timer for a browse which would execute a sub-routine. One could then put up or take down a show pop up.  What I really wanted was the ability to have the browse re-execute to add or delete records. This would also allow for the closing of a browse if nothing is happening or putting up a msgbox which requires a response. No response in a given fine the. Record is exited. This is similar to what happens on some websites where one is prompted about logging out after a. Set time of inactivity.
>
> In my example, the programmer would be responsible for deciding if the record should be saved first or just cancelled thereby losing any changes made.
>
> Richard
> Sent from my iPhone
>
>> On Jun 25, 2018, at 10:28 PM, Richard Kreiss via Filepro-list <filepro-list at lists.celestial.com> wrote:
>>
>> I did this years ago be counting the records to appear in the lookup or report and the dividing by the length of the scroll bar. That let me know how many records had to be processed before setting a 1 character field’s value to a graphic character for display. Ds=ds{ds when the execution value was met. You can even put up % complete values or display that value as a show.
>>
>> With a browse, you will need to set this as a subroutine to be run along with Any other processing. Keep in mind that once all the records are selected in a browse, moving through the records will cause the scroll routine to run again. You will need to block any key strokes that cause the browse to execute this sub routine.
>>
>> For Windows based computers, I have not seen the issue of a browse appearing to be frozen. This was an issue in the early ‘90’s.
>>
>> As for the report output, this was done for a client’s bookkeeper so that she could glance at a screen and have a visual idea of how far along the report generation was. Again, the speed of today’s machines has made this unnecessary.
>>
>> Richard
>> Sent from my iPhone
>>
>>> On Jun 25, 2018, at 3:40 PM, Walter Vaughan Jr via Filepro-list <filepro-list at lists.celestial.com> wrote:
>>>
>>> I had sort of the same Idea that one could show boxes/lines incrementing across the bottom of the screen  like  the illusion of a progress bar, however I'm curious how one would trap  knowing that you are not locked up. How would you know in the "prc= " code that you had gotten to the end and need to take it down? Typically after the browse I've only  checked for @bk keys. So one could change the show box status to "Completed" before checking for @bk's?
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Filepro-list [mailto:filepro-list-bounces+wvaughan=steelerubber.com at lists.celestial.com] On Behalf Of Fairlight via Filepro-list
>>> Sent: Monday, June 25, 2018 3:24 PM
>>> To: filepro-list at lists.celestial.com
>>> Subject: Re: Browse Lookups
>>>
>>> 1) Before your lookup, do a SHOW (or other NON-blocking) text display.
>>>
>>> 2) Set an increment counter to zero.
>>>
>>> 3) Every time that code block is executed, increment your counter.  If you want to handle it in multiples of 'x', do the calculation to determine if you're on that multiple (of, say...100 or 1000).
>>>
>>> 4) Every time it's time to print the message, update it with the incremented counter.
>>>
>>> 5) After the lookup is complete, take down or otherwise paint over your text display.
>>>
>>> 6) Profit.
>>>
>>> m->
>>>
>>> On Mon, Jun 25, 2018 at 03:06:24PM -0400, Scott Walker via Filepro-list thus spoke:
>>>> I'm doing a browse lookup.
>>>>
>>>> There is some code executed for each record which causes many of them
>>>> to be dropped  (that is good).
>>>>
>>>> But when a lot of records are dropped (like thousands) I want to flash
>>>> a message telling the customer that the system is doing some searching
>>>> and is not "frozen".  When the system is not actively searching for
>>>> records to include, (like when it's filled up the entire browse lookup
>>>> window) I want this message to be cleared or when it's gotten to the
>>>> end of the file it is searching through.
>>>>
>>>> Has anyone figure out how to do this?
>>>>
>>>> I'm having trouble figuring out where the right place to put the code
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus