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

[Dennis Malen]

Brian,

I have use PUTENV successfully in other processing. That is the way I was 
taught.

I still have not heard Ken say that I should be using PUTENV or that it 
violates filePro protocol.

Hopefully Ken or someone will clarify to everyone's satisfaction. I'm under 
the impression I should use it as it works. If I don't use it, then it 
doesn't work.

Dennis
----- Original Message ----- 
From: "Brian K. White" <brian at aljex.com>
To: "filePro mailing list" <filepro-list at seaslug.org>
Sent: Monday, March 21, 2005 5:49 PM
Subject: Re: printer file "name" - problem RESOLVED!!!!!


>
> ----- 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
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>