Sounds like a good idea. Where would you think I'd post it? Just as a message, or is there a FAQ section here somewhere?

Scott

>It sounds very valuable! Maybe you should do a faq or a file about this. I think a lot of people have problems with this .frx file stuff.
>
>>Sorry it took me so long to respond. I was on a much-needed vacation... :)
>>
>>I subclassed my project (using the new Project class), and inserted some code into the BeforeBuild method that scrubs each .FRX in the project immediately before building. It adds a few seconds to each rebuild, but that's a price I'm willing to pay to ensure that I don't forget to scrub those reports before distributing them.
>>
>>Scott
>>
>>>Correct me if I am wrong, but it really only has to be done once, just before you do the final compile of the app that you are going to distribuate(sp?). If you were clever (and I am NOT) you could probably even make a hook in the project so that on build, it will open all the .frx's and zap those fields.
>>>
>>>>Todd...
>>>>
>>>>Well, that's what I was afraid of. :) We're heading down that path, but I was hoping to avoid it.
>>>>
>>>>Scott
>>>>
>>>>
>>>>>Scott,
>>>>>
>>>>>There have been a few articles kicking around about this. Basically, you need to use the .frx as a table and delete the contents of the "tag" fields.
>>>>>
>>>>>>A clarification:
>>>>>>
>>>>>>To summarize: If an FRX fails to find *its* default printer in the current workstation's set of defined printers, it will print to the default Windows printer and ignore the setting of SET("PRINTER", 3).