>>Yes. That stuff in record 1 of every .FRX is specific to the default windows printer when the report was last modified. This is not necessarily the printer nor the specifics of the default printer on someone else's computer.
>
>With all due respect (and that's a lot, Mark :) I think the answer should be "No, don't edit it before you MODIFY REPORT, edit it after you MODIFY REPORT, and before you compile it into your APP/EXE." It's the MODIFY REPORT command which puts the printer-specific info into the frx.
>
>If you have MODIFY REPORT commands in your APP/EXE to allow the end-users to change the reports before using them, I'd suggest you put code after the MODIFY REPORT commands to do the Tag, Expr1, Expr2 editing in your code. Unless you can rely on the fact that the user who is editing the report will always be sending that report to the printer which was set as their windows default when they modified it.
>

Correct-o-mundo. I mis-read her reply. However, I always exclude the reports from my APP or EXE because my users always want something changed. I just stick them in a REPORTS subdirectory in the App's data directory on the server and set an additional path to that in the APP/EXE. My server tree looks something like:

* VFPApps
* -AppName
* -Data
* -Reports
* -AppUpdts && where I put APP updates

I launch a very small generic VFP EXE that looks for APP updates in the AppUpdts subdirectory. The EXE then copies new and updated files to the app home directory on C:, then executes a DO MyApp.APP. Slick way of providing newer versions of the APP.