[archive] Requesting Enhancements for WIN$PRINTER

[Migrated content. Thread originally posted on 08 August 2006]

So that we can better allocate our development resources, we need your feedback on the library routine, WIN$PRINTER. Specifically, we'd like your input on the following:

How extensively are you using WIN$PRINTER?

In what ways are you using this library routine?

Do you use WIN$PRINTER in a Thin Client environment?

Do you have enhancements to WIN$PRINTER that you would recommend we implement? If so, please tell us what they are.

I am using WIn$PRINTER a lot for forms such as statements, invoices, etc. Primarily to produce the artwork, boxing and a selection of fonts.

I will be moving to thin client soon......

It is not the fastest kid on the block.

I cannot seem to mix fonts on one line - although I used to be able to do so in the old DOS days with simple matrix printers?

The order of printing normallines to the printer and the WIN$PRINTER calls is crucial to getting it to work, mioxing the calls and the standard write print-line statements can cause strange results.

It would be nice if the output could be previewed in a simple way.

Keith

[Migrated content. Thread originally posted on 08 August 2006]

So that we can better allocate our development resources, we need your feedback on the library routine, WIN$PRINTER. Specifically, we'd like your input on the following:

How extensively are you using WIN$PRINTER?

In what ways are you using this library routine?

Do you use WIN$PRINTER in a Thin Client environment?

Do you have enhancements to WIN$PRINTER that you would recommend we implement? If so, please tell us what they are.

We use Win$printer extensively in our code which is written as a multi tier application. The critical printing is done in the background from processes on the server (run under the Acuconnect service). Many print jobs are responses to transactions. For example , we print bar coded labels in response to a Material Receipt transaction. The application figures out where what printer to print to and the user never has to use the printer selection dialog box and the printer isn't even installed on the users client workstation.

This works ok when everything is setup correctly. But if anything is wrong it gets ugly. It seems like print driver errors and other Windows issues regarding the spooler or the printers can confuse Win$printer and cause the process to hang or throw an exception.

It would be nice if errors could return control back to the program that called
Win$printer so the application could handle it better.

[Migrated content. Thread originally posted on 08 August 2006]

So that we can better allocate our development resources, we need your feedback on the library routine, WIN$PRINTER. Specifically, we'd like your input on the following:

How extensively are you using WIN$PRINTER?

In what ways are you using this library routine?

Do you use WIN$PRINTER in a Thin Client environment?

Do you have enhancements to WIN$PRINTER that you would recommend we implement? If so, please tell us what they are.

We use Win$printer extensively in our code which is written as a multi tier application. The critical printing is done in the background from processes on the server (run under the Acuconnect service). Many print jobs are responses to transactions. For example , we print bar coded labels in response to a Material Receipt transaction. The application figures out where what printer to print to and the user never has to use the printer selection dialog box and the printer isn't even installed on the users client workstation.

This works ok when everything is setup correctly. But if anything is wrong it gets ugly. It seems like print driver errors and other Windows issues regarding the spooler or the printers can confuse Win$printer and cause the process to hang or throw an exception.

It would be nice if errors could return control back to the program that called
Win$printer so the application could handle it better.