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).