Hi Albert,

Thanks for the feedback!

Hugh


>Hi,
>
>I got this to work with basically two problems having to be solved:
>
>a) the DOS app was using up most of the CPU cycles (about 95%); I was solved most effectively by using a product called "TameDos" that cut the cycles down to about 3% (great product, www.tamedos.com).
>
>2) the second was being able to change printers on the fly to whatever the user submitted (via a field in a record in a table); this used to be done by shelling out to DOS and issuing a CAPTURE Q=QueueName etc. This was failing as Capture.exe (from Novell) was too big to load in memory. Changed the code to instead issue a NET USE LPT1 \\\queuename ie. using NET USE commands to redirect the print job. This worked as much less memory was needed to do this.
>
>Thanks for the suggestions,
>Albert
>
>>Hi Kevin,
>>
>>One thing to watch out for is the way traditional DOS commands work in Fox2.6 in a DOS Window. If your application shells out to DOS you'll need to create some DOS batch files to set your pathing properly for those sessions.
>>
>>Hugh
>>
>>>Hi Albert
>>>
>>>Our experience of this type of scenario is Yes it will work. If the application is run in a DOS Window, then the processing time will be reduced, although this can be altered.
>>>
>>>The main problem will be ensuring that the printer drivers are working ok. We have found that Windows "gets involved" in our 2.6 printing. If the output is to a laser, then you have no real problems, but if it is to a dot matrix, then come back to me and I will fill you in on what we had to do to preserve formatting and speed.
>>>
>>>HTH

Microsoft hears loudest what the VFP community says about Visual FoxPro by looking at the bottom line!

Support the product. Buy the latest version!

Hugh Winters @ WorldData 408-512-1131