Can filepro do drill downs like acess?

[Jerry Rains]

On Thursday 25 March 2004 14:13, Tony Freehauf wrote:
> can filepro do things that look like acces drill downs?
> can we compete with this kind of programing?
> thanks
> old tony

Absolutely.  I wrote a process table where I did DrillDowns and AutoFills.  I 
called it DrillDown, but I actually used the AutoFill routine more.  They 
were basically the same except DrillDown used browse lookups where AutoFill 
did not

You can do DrillDown with straight filePro.  The trick is to do a PUSHKEY 
"ENTR" just before the browse lookup then use WAITKEY to trap the keystrokes 
after the browse lookup exits.  I kept track of which keys had been pressed 
in a dummy variable then looped back to the browse lookup with my dummy 
variable as the key.  The biggest problem I had was some idiot pressing BREAK 
which WAITKEY doesn't handle.  I asked fP to fix that several times and 
finally gave up and wrote a 'C' program (my first one) to simulate it.

I call it 'waitkey'.  It allows me to have absolute control over the keyboard.  
If the user pressed Break I knew, it, or Ctrl-C, Insert, Shift-F1, you name 
it.  If the terminal type supported the key I had a filePro-like nemonic for 
it.  It even supports keys that aren't defined in the terminfo file for the 
terminal type.   Have you ever wanted to reset @SK or @BK?  Or use "Del" to 
delete the character under the cursor?  'waitkey' lets you do that.  For more 
on 'waitkey' see below.

Another thing that 'waitkey' did for me was I was able to use it instead of 
the normal filePro field routine.  The trick here is to only use @WEFxx 
processing.  I made a DrillDown database that I used to tell me where each 
field went on the screen and what properties it had and called that at the 
end of each @WEFxx processing then jumped out of it to a cursor path routine 
that determined the next field.  This allowed me to do AutoFill within a 
field using normal, not browse, lookups and a whole lot more.

My database has full control over every field.  The field could allow the user 
to change it or not.  If the field was not changeable, when the user started 
typing a character that wasn't in the drill down field the character wouldn't 
print.  It also had an insert mode so that the user could add new fields to 
the record or change the field.  

More on 'waitkey' . . .

I used 'waitkey' just last week as part of the solution to the USER problem I 
had with Break.  I replaced the WAITKEY in the @ENTSEL processing with 
'waitkey' and got rid of some of the Breaks and used the technique above 
(PUSHKEY "ENTR") to get rid of the ones from browse lookups.

Originally, I was going to use terminfo routines to determine which key was 
pressed, but many of the function keys don't have entries in the files, so I 
wrote in an initialization routine that asks the user to press all of the 
function keys in a specific sequence the first time 'waitkey' is run and it 
builds a $TERM.raw file that 'waitkey' uses to determine which key is 
pressed.  Since the character for ASCII and Crtl- keys is always the same 
those keys don't have to be pressed during initialization.  This only has to 
be done once.  

The scoansi TERM type does all Ctrl- keys except Ctrl-S and Ctrl-Q, all 
arrows, PgUp, PgDn, Home, Delete, Insert, End, Backspace, Tab, Shift-Tab, 
F1-F12, Shift-F1-F12, Ctrl-F1-F12.  Oh, it does A-z, 0-9, etc too.

Jerry Rains