Weird fiePro Behavior

[Nancy Palmquist]

George Simon wrote:
> 
> There are many work-arounds, I was just wondering why this is so or actually
> "How does filePro determine if a field is protected?"
> I guess it does it by reading the screen until it finds the first reference
> to the field and then it makes its determination.  But why doesn't it apply
> the same logic when accepting entries in the cursor path screen?
> 
> George Simon (IT Department)
> American River Logistics, LTD
> 614 Progress St.
> Elizabeth, NJ  07205
> Phone:(908)354-7746      Fax:(908)354-7491
> mailto:george at worldest.com
> http://www.americanriverintl.com/
> 
> -----Original Message-----
> From: GCC Consulting [mailto:gcc at optonline.net]
> Sent: Tuesday, April 20, 2004 11:09 AM
> To: 'George Simon'; 'Filepro-List'
> Subject: RE: Weird fiePro Behavior
> 
> George wrote:
> 
> You can have the same field on a screen 2 or more times.
> You can have one or several of the field instances protected.
> You can include the field in the cursor path, as long as one of the
> instances is
> unprotected.
> But you can't have a statement in your processing such as:
> screen ,field_number
> unless the unprotected instance is higher than the protected one on the
> screen.
> 
> Why does filePro allow a field to be included in the cursor path and then
> ignore
> the contents of the cursor path when the screen statement is encountered?
> 
> ---------------------------------------------------------------------------
> I can't answer your question.
> 
> However, you might consider using a protected dummy fields to display the
> value
> of the real unprotected field.  Then it won't matter where you place the
> real
> field on the screen.
> 
> Richard Kreiss
> GCC Consulting
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list

George,

It seems that in your application, you accidentally placed the same
field on the screen twice.  The cursor path allowed you to list it
because it was on the screen, but because it is not usually a reasonable
practice to do this, you are complaining because the 
	SCREEN ,field 

logic did not work.

I think that most of us would consider that a programmer mistake and
would not expect filePro to catch it as a mistake or error.

FilePro does not tell you when you place two field too close together,
put the wrong dummy or real field on the screen, take fields off the
screen and leave them in the cursor path, make the color of the
foreground and background the same so that the data can not be seen, put
a show over real data on a screen, etc.

I can think of lots of things that I have done wrong on a screen and
hate to admit the time some of those stupid mistakes cost, but that is
my problem.  I do not expect filePro to do anything about it, and in
some cases I am glad it does not because I might have intended the
behavior I accidentally created.

I call filePro to task when they say "this command will do this" and I
try it and it does not "do this".  That is clearly a filePro bug.  But
to most programmers the strange behavior(s) that can be created might be
exactly the feature we need to accomplish something.  A trick that can
be exploited to create a two line browse list or a peek-a-boo field or a
mass wild card search update.  All things I have seen suggested to be a
bug by one programmer because they did not expect the behavior but
treasured features by others that know of their usefulness.

I realize it would be wonderful if filePro would make sure that every
screen and process table I write contained no strange stuff, but I think
of filePro as a tool not my mommy and I want it to let me make my own
mistakes.  I only want a warning when I do something that will make
filePro break down completely.

I like to treat my customers the same way when I program.  In my first
application (in 1981 with filePro - can you believe it?) I remember
having a customer name and address entry where I required the user to
enter the name , address, city state and zip before they left the
screen.  I discovered after the application had been in place for some
months that when the users did not know the zip or city or state they
filled the field with junk data.  Now I had a data base with bad
information and I learned that if the data did not make my application
break, I should let them leave it blank if they did not know it.  It is
much easier to tell that the data is unknown when it is missing.

Good lesson - Sorry but I guess I am rambling.  Too many interruptions.

Nancy
-- 
Nancy Palmquist 
Virtual Software Systems
PHONE: (412) 835-9417			Web site:  http://www.vss3.com