MY Eyes have been opened

[Brian K. White]

----- Original Message ----- 
From: "Doug Luurs" <doug at borisch.com>
To: "Anthony Terrible" <tony at vegena.net>; "File Pro List" 
<filepro-list at lists.celestial.com>
Sent: Thursday, February 09, 2006 2:13 PM
Subject: RE: MY Eyes have been opened


> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf
> Of Anthony Terrible
> Sent: Thursday, February 09, 2006 1:36 PM
> To: File Pro List
> Subject: RE: MY Eyes have been opened
>
>
>   I have participated and watched this list over the weeks
> and I'm sorry but
> it just seems comical to me. While I will admit that most if
> not all of you
> are better programmers than I, I can't for the life of me logically
> understand why anyone is still using or recommending Filepro.
> More then several people have said over the last few weeks that
> they are dropping Filepro and all for the same reasons, it hasn't
> kept up with the trends and most everything you want or need to
> do now is impossible or very difficult to do with Filepro.

Recommend Filepro .. I would.  It's a stable database with a LOT of
Power (If you know how to use it).

I don't know if you are referring to applications or the fptech staff
To add something to Filepro.  I can't speak for the later one, but as
far as making a application in Filepro, I can.  I've got our Filepro
System things that some people would say "how did you do that?".

As I stated in a earlier email on this subject, I have a 2D barcode
Reader / Decoder that I wrote in about 50 lines of fp code.  Nothing
Hard about that.  You need to know what the data string looks like,
And use INKEY to read it.  I've not found anything (and I mean that)

---------

I did it with @key at one place.
There were bar codes being read that I didn't produce and couldn't decipher 
out of the blue ("227354-ab4" is meaningless unless someone tells you it's a 
model number), and other barcodes that I did produce (from filepro, using a 
soft font downloaded to the printer via %"filename" printcode).
The codes I produced made up a sheet or two of commands where the operator 
shoots the gun at a barcode labeled with whatever the command does.
Then shoots the gun at the barcode on some paperwork or a box or whatever 
that I didnt produce but I know how to interpret the bar code data based on 
the special command barcode they just previously read from my sheet.

The data from the code I didn't produce are usually just number or 
alphanumeric that can't be deciphered just by reading them. You have to know 
it's a shipment number or a cotainer number or a whatever...

But, the barcodes on my command sheet are another story. Every one of those 
begins with a character that doesn't appear on any normal barcode (a 
weakness, because that could change someday)
Normally the terminal is just sitting at entsel, and there is an @key that 
matches the first character of all my codes. I think I might have actually 
used @ as my special prefix character too.
The @key routine does and input very early, maybe the very first line. (Most 
readers have an option to terminate reads with CR, which makes input work, 
but waitkey/inkey, whichever one of those doesn't loop tightly eating cpu, 
is even better. If any, I never use either so I'm not up on'm )
So the @key routine "sees" everything in the barcode after the first 
character, which entsel ate. Those characters tell the @key routine what to 
do. Some of the special codes did things all by themselves, some prepared to 
accept data from another bar code on the paperwork/boxes/whatever.

The end result is, the user is sitting at a normal entsel in a normal screen 
in the app that they are already used to using for years, only now, they 
have the transparent option of shooting the barcode reader at something, or 
not, using the same screen the way they always did. That is mostly for 
office workers with neat little pens added to their stations they can swipe 
across paperwork. Then dock/garage/warehouse people can have guns and and 
almost never touch the keyboard except to boot up once in a while. They just 
shoot the gun at one of my command codes now and then.

The command code sheet is generated from fp, so they can spit out new ones 
at will when the existing ones get damaged or when they add a station or 
when we add more features.

I think I'd use a field now though. It's a little unsafe having them at 
entsel when they might shoot an ordinary barcode, which would trigger all 
manner of screen switches and menu choices and record updates all in a blur. 
I think for the warehouse worker screen I might have done that actually, and 
left it as I described for the office workers. Most codes had start/stop 
characters I could make an @key for to trap accidental reads, also the guns 
usually have an option to tack on start/stop characters. Between them I 
think I was able to make the office worker entsel pretty safe too actually.

But, let's be honest. This was easy for us because the hardware makes it 
easy because it's a keyboard wedge.
Maybe the @key trick means filepro gets some credit for having @keys, but it 
just doesn't seem like that amazing of a thing that any other language 
couldn't do just as easily.
I know I could write a shell script that reads bar codes and even reads my 
special command codes, including interpreting them and reacting to them 
appropriately.

But it sure was fun to watch the users playing with it. nice wow factor 
there.
Sadly, they are one of those customers that periodically asks for a lot, 
gets it, then doesn't use it. And no one else has happened to need anything 
similar, so I've not touched that stuff sice then and didn't get the chance 
to do any of the ideas for enhancements that were going around in my head at 
the time.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!