>Hi Ed,
>
>The SET('PRINTER',2) command gives me the printer name, whereas defprint requires the portname/sharename to be able to set the default printer. I don't really want to use winscript cos changes are going out to quite a few remotes and my users aren't going to be happy if they need to install anything at all. For me the ideal solution is one which requires as few extraneous files as possible.

Well, the obvious solution of WSH, which has a SetDefaultPrinter method, and gets around all the headaches of variances in the method of identifying ports and UNC, is not appealing to you. OTOH, WSH is there on Win98, Win2K, and any Win32 platform with IE 4 or later, and makes a ton of functionality available in a consistent fashion, isn't going to make you happy. The availability of the various COM objects (Wscript.Shell, Wscript.Network, Scripting.FileSystemObject, Scripting.Dictionary, Vbscript.RegExp) as well as the complete availability of the scripting platforms far outweigh any disadvantages theymay incur, they're going to have to be present in the near future in the MS environment IAC from my POV, and, well, frankly, I don't like having to do things hard when they can be done easily, portably and at no added cost for the distribution, but that's your decision, not mine. Extremely shortsighted IMO, and what you give up in functionality and the availability of VBScript/JScript and the distributed COM objects is not a good decision. But that's my opinion...I'm fairly adept at working with the API, can live in the Platform SDK, and the decision to incorporate WSH into all my apps was a complete no-brainer. COM's a helluva a lot easier than jerking around with VFP and kludging up API code to avoid having a great means of lightweight installation and maintenance at less than the cost of a floppy to distribute and fewer support headaches.