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

[Dennis Malen]

----- 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 3:19 PM
Subject: Re: printer file "name" - problem RESOLVED!!!!!


> Ken,
>
> I did test your suggestion that "nocodes" does not have to be defined in 
> the config file. I removed it and left the processing the same. It 
> overrides the defined printer in rreport and prints the report correctly 
> to the screen.
>
> Those of you who thought otherwise, just learned something new.
>
> Anyone who wants to see the processing let me know.
>
> Thanks again, Ken!
>
> Dennis Malen
> 516.479.5912
> ----- Original Message ----- 
> From: "Kenneth Brody" <kenbrody at bestweb.net>
> To: "Dennis Malen" <dmalen at malen.com>
> Cc: <filepro-list at lists.celestial.com>
> Sent: Friday, March 18, 2005 10:49 PM
> Subject: Re: printer file "name" - problem RESOLVED!!!!!
>
>
>> Quoting Dennis Malen (Fri, 18 Mar 2005 17:45:14 -0500):
>>
>>> Ken,
>>>
>>> The only thing I can think of is that when I defined nocodes as a
>>> printer in
>>> filePro that I did not include a destination file. I'm not sure. The
>>> processing did not work so I asked the list to comment.
>>
>> The PRINTER TYPE "nocodes" command in your processing has absolutely
>> nothing to do with the filePro printers that you have defined.  The
>> only thing that PRINTER TYPE does is set the printer type.  It does
>> not use, nor does it even look at, the printers that you have defined.
>> There is no need to even have a printer defined with the name "nocodes".
>> Creating one, or changing one that is already defined, will have zero
>> effect on the PRINTER TYPE "nocodes" statement, and it will have zero
>> effect on your processing as a whole.
>>
>> [...]
>>> The more important point is there was a diverse opinion on how the
>>> processing should work and a number of people were confused. I wanted to
>>> make sure that I clarified the issues I raised and published something
>>> that
>>> I know works. If anyone had a diiferent approach then I requested they
>>> share it with us.
>> [...]
>>
>> The thing is, you now say that it "works", when you haven't made any
>> changes to the processing that "didn't work".
>>
>> --
>> KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
>> http://www.hvcomputer.com
>> http://www.fileProPlus.com
>>
>>
>>
>