>>
>>Paul,
>>
>>Just another note on this. I overlooked the fact that, according to your message you're using FPW rather than FPD. I don't believe that FPW either needs or uses GENPD, it uses the Windows printer drivers. While what I wrote about the D: drive still applies, printer information wouldn't. There is, however, a way to change the default printer driver to Generic / Text Only in Windows. If this is the problem, please post a response.
>>
>>George
>
>George,
>
>Thanks for you replies on this. Let me give you a little more info. We are running a FPW application which is very large. We have some legacy FPD reports, which it is my understanding require the GENPD drivers, as well as few areas where we are sending output directly out to the printer. The biggest concern is that because our application was originally a Dos app, there are calls to SET PDSETUP all over it, and to complicate matters, we actually have about a dozen different version of the software for different markets that we would have to go through thoroughly, followed by extensive testing. Rather than do all of that, we would really like to be able to figure out how to get whatever D reference there is out of genpd.app or foxuser.
>
>Again, any suggestions you have are appreciated.
>
>Thanks again,
>Paul

Paul,

Well, the most obvious way out of this is to simply modify the reports in Windows so that they're converted and you can simply be done with the entire issue of GENPD. I know that this probably isn't the solution you want to hear, but, nevertheless, it's the one that makes the most sense. After all, sooner or later, you're going to have to make modifications and when you do you'll have to make them in FPD or it will be converted. So how long you want to hang on to FPD becomes an issue as well.

In terms of the FOXUSER resource file, information contained in there does not reference a drive letter. I glanced at the DOS version of mine and it didn't. You might want to check this by setting RESOURCE to off, opening the table and browsing. Look for PDSETUP in the ID field. You might want to check the DATA memo field just to make sure.

If the GENPD project was modified, regenerated and distributed, that could have a reference to D:. You might check that. As a side note , and I don't know if this will impact or not, I marked the driver tables (p_codes.dbf and fonts.dbf) as excluded. I made some modifications (got it to recognize the _PPITCH system variable) and I did this when I recompiled. If these aren't marked as excluded, you won't be able to add new printer types.

You can use the Find option in Filer to search the prg/mpr/spr files of the project(s) for D: and PDSETUP. Still, it sounds like something in the CONFIG.FPW file is pointing towards D:. Perhaps it was included in a project

As for output directly to the port, I abandoned that practice years ago. I've had to deal with some pretty hairy reports (variable number of columns, etc.) and have yet to find one that I couldn't do with the report writer.

One last note, if you decide to make the conversion to Windows (FPW), I'd save all the original, DOS only report separately. These can be used to directly write a report to a file without the PROMPT clause (in other words, using the same syntax you used in FPD). If both definitions (DOS and WINDOWS) are in the file, then you've got to stick with the PROMPT business.

That's about all I've got at the moment. If I think of something else, I'll post it.

Good Luck,

George