printer file "name" - problem RESOLVED!!!!!

[Brian K. White]

----- Original Message ----- 
From: "Dennis Malen" <dmalen at malen.com>
To: "Kenneth Brody" <kenbrody at bestweb.net>
Cc: <filepro-list at lists.celestial.com>
Sent: Monday, March 21, 2005 5:23 PM
Subject: Re: printer file "name" - problem RESOLVED!!!!!

I'm still waiting for some sort of response to what I pointed out.

As far as I'm concerned, it's a bug that putenv PFONEHEAD works.
I quoted Ken stating clearly that variables that control fp's behaviour do 
not affect a currently running instance of clerk/report when you use putenv 
in processing.

Is it a change with some version of fp that means above is no longer true, 
or is it a difference between clerk & report? or is it a fluke that some 
variables work and some don't ? Or is it a bug that will get fixed in some 
future release now that we have uncovered it?

Do I have to perform a test on every variable just so I can document the 
behaviour of them all instead of counting on a rule?

I think it's wrong to allow it to continue since look what happens? Dennis 
is doing this all wrong, but, since as far as he can see "it works", he's 
not even considering fixing it, and so when the bug is fixed, his code 
breaks, yadda yadda.

And there is reason to for the behaviour to be like I'm claiming it's 
supposed to be. It's only "working" for Dennis in this one particular case. 
It's really "wrong" and gets in the way in other cases where you are writing 
code, depending on certain behaviour. It could be a lot worse than some 
unsightly output. The variable in question could just as easily be one that 
changes what data gets collected in the report and ends up causing a report 
to be wrong through no fault of the programmers. Suppose it was PFSKIPLOCKED 
or PFMBTO or PFREADONLY and I was in a report that runs other reports and it 
was critical that no records get skipped nor used when being updated in the 
top level report but it was ok to skip some in the sub/child reports? I 
would set one of those variables with putenv secure in the knowledge that 
they can only possibly affect the reports run in the system commands and not 
the top level report I'm running in right now.

It's equally OK if it works like we proved PFONEHEAD works, as long as ALL 
behaviour modifying variables work the same way and it's documented and it 
doesn't change and as new variables are added they all stick to the same 
plan.

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