A GDI printer relies on the host computer's processor to generate printable pages. Most host-based printers on the market today use the GDI interface built into Windows. Because they don't need a processor of their own, host-based printers tend to be less expensive than conventional printers. But because they share your computer's processor, they may be slow and they may slow down your other computer work. How fast these printers operate depends on how powerful the host computer is and how occupied it is with other operations. You cannot send printer control codes (escape sequences) directly to the printer since it cannot process them. They just go out to 'la la land' or worse, lockup your printer as I've seen in some cases.

>Tracy, call me stupid if you like ... but ehh, what is a GDI printer ?
>
>I suppose it is something with Graphical Data Interface ?
>
>Two things now (if this is about printers accepting graphics only) :
>
>Why didn't I ever have this "doesn't work !!" from a user ? okay, this is not 100 %, but I just wonder. AND, I don't suppose we can deal with that indeed. BUT :
>
>We can deal with that afterall, because at our move from FPD to VFP we managed to use the normal BillGates drivers as they are supposed to. But rememeber, we have official drivers to all right from the beginning, and I mean, long before FP came up with it (so, already in FoxBase). I really can't tell what this does to us regarding this problem. Anyway :
>
>We don't use that kind of (normal) MS drivers, because they can't control all there really is. I mean, open a printer, browse through the tabs, and I think you recognize that various stuff is in there which can't be controlled programmatically. And we already contolled all there is ... (the Esc sequences allow for all, right ?).
>
>Concluded, our setup CAN solve the GDI thing just as well. Only not for us.
>
>Please let me know what you think.
>
>Peter
>
>
>
>
>>The only problem is that it does not work with GDI printers (if you need to send ANY codes to the printer for formatting, etc) and that is basically the necessity for the change. As it stands now, all users with GDI printers have limited reporting capability until all reports are converted.
>>
>>Tracy
>>
>>>>Has anyone come up with a good way of converting a report prg created with @...say to an .frx? Wouldn't that be great??? I just have too many to convert...getting monotonous...
>>>>
>>>>Tracy
>>>
>>>
>>>Tracy,
>>>
>>>Like I just replied to Hugh (message #701454), there could be just the other way. IOW, just let your old reports (normal PRGs) run like they did before.
>>>However, it is the question whether you want that, or rather have them as official reports.
>>>
>>>Anyway, *if* you could go for just letting them run as before, there is really no functional difference to the before situation. There is one thing though I didn't manage yet (but what can be done), and that is having smooth lines (horizontal and vertical), I mean, not dashed, around the things.
>>>
>>>What do you say ?
>>>
>>>Peter