>>My experience with label printers has been that not using the ReportWriter or any of the Windows GDI functions gives the best control; the label printers that I work with usually offer an ActiveX control that bypasses the normal Windows printing layers to avoid problems like form position resets, or I've written my own driver in C to do it; I normally do not want the Windows GDI stepping in and doing things like resetting the printer to a standard mode between label printing, and don't want the spooler stepping in to buffer and defer output - most of my applications that use label printers want the label generated immediately, not when the spooler gets around to it, and I normally need to either use form addressing of the printer, like the Monarch label printers use, or I want to send detailed control sequences without Windows interpreting them.
>>
>>Just my $0.02
>
>I agree there Ed, just that I've still got to drive these particular printers, and also from within FPW 2.6 as well.
>The FAQ helped too thanks. Just got one problem remaining and that is if I modify the Expr field then NT4 errors loading the print driver if the named printer is UNC pathed, probably a spooler issue. Win 2000, Win 95 no problem. <s>
>

In all probability, it's an issue with the driver not being installed for the UNC, with the UNC treated as a port rather than as a file; NT treats an unassigned UNC as a port, and it really, really wants a printer driver assigned. I'd try explicitly installing the UNC as a named Windows printer with a driver association, even if it's just the Generic/Text Only driver; it will know how to manage GDI output routed to the UNC.

You might want to investigate using the Wscript.Network COM object, which can assign/attach/detach printers and ports directly; you can try firing up a batch job from FPW that launches a WSH script using the START verb.