Go into the Knowledge base (Its icon is a purple book)

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