View/Pro and accessing Windows Printer API (gdi32.dll)

Hello All! I am looking to add native printing support to my REBOL applications for Windows, but I am running into a problem with the library component of View/Pro. Here's the story: The following has C source code for sending raw data to a printer on Windows. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_93g2.asp Converting it to View/Pro was going well until I hit the OpenPrinter routine!. Here's a transcript of my efforts:

>> gdi32: load/library %gdi32.dll >> startdoc: make routine! ["Start Document" hdc [string!] docinfo

>> openprinter: make routine! ["Open Printer" pprintername [string!]

>> gdi32: read %/c/windows/system/gdi32.dll >> find gdi32 "OpenPrinter"

Hi Bo, Try using %winspool.drv instead of %gdi32.dll for OpenPrinter function. (Works here on W2K) HTH, -DocKimbel. Bohdan or Rosemary Lechnowsky wrote: [...]

Hi Doc - do you have a sample of the code you use? Paul Tretter

Hi Guys, << Try using %winspool.drv instead of %gdi32.dll for OpenPrinter function. (Works here on W2K) >> Ditto. You'll probably also need to use %winspool.drv for ClosePrinter. --Gregg

I want to work with you on this. I also have /Pro and but haven't use library capabilities much. Paul Tretter ----- Original Message ----- From: "Bohdan or Rosemary Lechnowsky" <[amicom--sonic--net]> To: <[rebol-list--rebol--com]> Sent: Thursday, June 27, 2002 11:31 AM Subject: [REBOL] View/Pro and accessing Windows Printer API (gdi32.dll)

> Hello All! > > I am looking to add native printing support to my REBOL applications for > Windows, but I am running into a problem with the library component of > View/Pro. Here's the story: > > The following has C source code for sending raw data to a printer on

>

> Converting it to View/Pro was going well until I hit the OpenPrinter

> Here's a transcript of my efforts: > >> gdi32: load/library %gdi32.dll > >> openprinter: make routine! ["Open Printer" pprintername [string!] > phprinter [string!] pdefault [string!] return: [integer!]] gdi32

> ** Access Error: Cannot open OpenPrinterA > ** Near: openprinter: make routine! ["Open Printer" pprintername [string!] > >> find gdi32 "OpenPrinter" > >

Hi Paul, Nope, just looked at VB WINAPI viewer and tested using Bo's sample replacing gdi32.dll by winspool.drv. I just checked that 'make routine! was working for 'OpenPrinter. -DocKimbel. Paul Tretter wrote:

Thanks Doc and Gregg! At 08:26 PM 6/27/02 +0200, you wrote:

OK, %winspool.drv is the correct library to use. Thanks! But now I have other problems. Hopefully some of you familiar with C and the library component of View/Pro will be able to help. Continuing from what I had in my original message (contained below):

>> openprinter: make routine! ["Open Printer" pprintername [string!]

>> hprinter: copy ""

>> ret: openprinter "Brother MFC3100C" hprinter ""

>> hprinter

>> kernel32: load/library %kernel32.dll >> getlasterror: make routine! [return: [long]] kernel32 "GetLastError" >> ret: openprinter "Brother MFC3100C" hprinter ""

>> a: getlasterror

>> hprinter

>> ret: openprinter "Brother MFC3100" hprinter ""

>> ret: openprinter "Brother MFC3100C" hprinter ""

>> startdocprinter: make routine! ["StartDocPrinter" hprinter [char*]

>> dwjob: startdocprinter hprinter 1 docinfo

>> getlasterror

>> ret: openprinter "Brother MFC3100C" :hprinter ""

>> hprinter

>> dwjob: startdocprinter :hprinter 1 docinfo

>> getlasterror

Hello Bo, First of all I have to say that I'm not a C guru ;-) But we(together with Pekr ;-)) were experimenting some time ago with Rebol DLL interface. We has also lot of problems caused mainly by lacking the good docs but finally we got to work rebol wrapper that is able to convert/proccess/load/save about 200 image formats!Really cool stuff. Unfortunately we couldn't get to work showing images directly from the dll to View but I've written simple intermediate library in C which will suit for that purposes... I think in your case you need to pass the hprinter value as a pointer to rebol integer!. You could try following method:

>> hprinter: make integer! 0 ;this create an integer value in Rebol

>> hpr_str: make struct! [i [integer!]] reduce [hprinter] ;this is a

>> probe third hpr_str ;this give us the value(data) of hprinter

>> phpr_str: make struct! compose/deep [pi [struct! [(first hpr_str)]]] none

>> probe third phpr_str ;now you can see the real pointer in memory to the

> OK, %winspool.drv is the correct library to use. Thanks! But now I have > other problems. Hopefully some of you familiar with C and the library > ;Shouldn't 'hprinter now have some value that indicates the pointer? I've > also tried specifying 'phprinter above as LONG, but that didn't do it

> ;Let's retrieve Windows' error code to see if there was an error > >> kernel32: load/library %kernel32.dll > == 6 > ;This means the handle is invalid according to

Hi, This one seems to work but i'm not sure that the result is correct : winspool: load/library %winspool.drv hprinter: make struct! [address [char*]][""] openprinter: make routine! compose/deep [ "Open Printer" pprintername [string!] phprinter [struct! [(first hprinter)]] pdefault [integer!] return: [integer!] ] winspool "OpenPrinterA" ret: openprinter "Canon Bubble-Jet BJC-4300" hprinter 0 ?? ret print ["Handle =" to-integer to-issue enbase/base hprinter/address 16] -DocKimbel. Bohdan or Rosemary Lechnowsky wrote:

Hi Bo, << ;hprinter is the handle that should be returned by 'openprinter above if I understand how 'openprinter works. >> I think you need to pass a buffer and then check that when the call returns. That's what I had to do to use the return connection ID from InternetDial. Here's the idea. I have to run right now, but I'll check back tomorrow, or mail me directly if this causes more confusion. win-lib: load/library %wininet.dll internet-dial: make routine! [ hwnd-parent [integer!] connectoid [string!] flags [integer!] rtn-conn-id [char*] ; LPDWORD - either string! or char* work here reserved [integer!] return: [integer!] ] win-lib "InternetDial" ;-- Internal support routines null-buff: func [ {Returns a null-filled buffer of the specified length.} len [integer!] ][ to-string array/initial len #"^@" ] ;-- Interface routines connect: func [ {Initiates dial-up connection. Returns connection ID (to use with disconnect) if successful; false otherwise.} dial-up-name [string!] /local id ][ id: null-buff 4 last-error: internet-dial no-hwnd dial-up-name dial-unattended id zero either all [(last-error = 0) (id <> null-buff 4)] [ last-error: none return to-integer to-binary head reverse id ][ return false ] ] HTH! --Gregg

Hi Gregg, On Saturday, June 29, 2002, 5:23:23 PM, you wrote: GI> null-buff: func [ GI> {Returns a null-filled buffer of the specified length.} GI> len [integer!] GI> ][ GI> to-string array/initial len #"^@" GI> ] head insert/dup make string! len #"^(00)" len :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

Thanks Gabriele! I have 3 or 4 versions of mk-string type functions floating around, most from when I first started with REBOL. It's time to clean things up. :-) --Gregg

Gregg, Your solution does return an apparently valid handle when I apply it to OpenPrinter, but StartDocPrinter still doesn't like it (returns a code of 6 which means "invalid handle"). Here's my script so far (beware of line-wrapping!): winspool: load/library %winspool.drv kernel32: load/library %kernel32.dll print "Define GetLastError" getlasterror: make routine! [ return: [long] ] kernel32 "GetLastError" print "Define OpenPrinter" openprinter: make routine! [ "Open Printer" pprintername [string!] phprinter [char*] pdefault [string!] return: [integer!] ] winspool "OpenPrinterA" print "Define StartDocPrinter" startdocprinter: make routine! [ "StartDocPrinter" hprinter [char*] dwlevel [int] lpbdocinfo [struct! [ cbsize [int] lpszdocname [string!] lpszoutput [string!] lpszdatatype [string!] fwtype [int] ]] return: [int] ] winspool "StartDocPrinterA" print {Create a Null Buffer - Thanks to Gregg Irwin and Gabrielle Santilli on REBOL list} null-buff: func [len][ head insert/dup make string! len #"^(00)" len ] print {Create Pointer Variable - Thanks again to Gregg Irwin} prin "Initial value: " probe to-binary hprinter: null-buff 4 print "Create DocInfo Struct" docinfo: make struct! [ cbsize [int] lpszdocname [string!] lpszoutput [string!] lpszdatatype [string!] fwtype [int] ][100 "Test Print" "" "" 0] print "Call OpenPrinter" print either zero? ret: openprinter "Brother MFC3100C" hprinter "" ["FAIL!"]["Success"] prin "Current value: " probe to-binary hprinter print "Call StartDocPrinter" print either zero? dwjob: startdocprinter hprinter 1 docinfo [["ERROR!" getlasterror]]["SUCCESS!"] halt If anyone has suggestions on why StartDocPrinter doesn't like the handle, I'd be very curious to find out! Thanks for all the help so far. I'm hoping that someday REBOL users can have graphical access to printers. I know it would make my applications a lot more useful! -Bo At 09:23 AM 6/29/02 -0600, you wrote:

Hi Bo, << If anyone has suggestions on why StartDocPrinter doesn't like the handle, I'd be very curious to find out! >> Below is a modified version of your script. Let me know if it works OK for you (I'm on W2K and some structures have changed compared to '95). If you have any questions about the changes I made, just holler. Hopefully I didn't muddy things up too badly. --Gregg REBOL [] winspool: load/library %winspool.drv kernel32: load/library %kernel32.dll print "Define GetLastError" getlasterror: make routine! [ return: [long] ] kernel32 "GetLastError" print "Define OpenPrinter" openprinter: make routine! [ "Open Printer" pprintername [string!] phprinter [char*] pdefault [integer!] ;[string!] We want to pass a NULL here for now. return: [integer!] ] winspool "OpenPrinterA" ; Added ClosePrinter so we can clean up while testing. Gregg print "Define ClosePrinter" closeprinter: make routine! [ "Close Printer" hprinter [integer!] return: [integer!] ] winspool "ClosePrinter" ; DOCINFO is used by StartDoc, and has a different structure than StartDocument, ; which the spooler uses. StartDoc is what you use for the actual printing ; commands (to a device context). The spooler uses the DOC_INFO_1 structure ; which doesn't have the size or type elements. print "Define StartDocPrinter" startdocprinter: make routine! [ "StartDocPrinter" hprinter [integer!] ;[char*] This needs to be an integer here. dwlevel [integer!] ;[int] lpbdocinfo [ struct! [ ;cbsize [int] lpszdocname [string!] lpszoutput [string!] lpszdatatype [string!] ;fwtype [int] ] ] return: [integer!] ] winspool "StartDocPrinterA" print {Create a Null Buffer - Thanks to Gregg Irwin and Gabrielle Santilli on REBOL list} null-buff: func [len][ head insert/dup make string! len #"^(00)" len ] print {Create Pointer Variable - Thanks again to Gregg Irwin} prin "Initial value: " probe to-binary hprinter: null-buff 4 ; You have to give it a datatype it understands (e.g. "RAW"), ; rather than an empty string. print "Create DocInfo Struct" docinfo: make struct! [ ;cbsize [int] lpszdocname [string!] lpszoutput [string!] lpszdatatype [string!] ;fwtype [int] ] reduce ["Test Print" "" "RAW"] ;[100 "Test Print" "" "" 0] ;!!! I CHANGED THE PRINTER NAME FOR TESTING !!! Gregg print "Call OpenPrinter" print either zero? ret: openprinter "HP LaserJet 4" hprinter 0 ["FAIL!"]["Success"] prin "Current value: " probe to-binary hprinter ; Have to cast the string buffer to a proper-endian integer. ; The string buffer trick is only needed for return filled (i.e. OUT) parameters. hprinter: to-integer to-binary head reverse hprinter print ["Printer handle:" hprinter] ; Don't forget, for structures that *do* have a size element, that you have to ; set it before the call. ;print "Set docinfo structure size" ;print docinfo/cbsize: length? third docinfo print "Call StartDocPrinter" print either zero? dwjob: startdocprinter hprinter 1 docinfo [["ERROR!" getlasterror]]["SUCCESS!"] print "Closing Printer" print either zero? ret: closeprinter hprinter ["FAIL!"]["Success"] halt

Thanks Gregg! What a wonderful bunch of help I've received in getting this working! I hope others on the list have gained some insight as well on using the library component! It appears to work now, but is giving me fits on my home printer (but no errors). I'm going to try it on a client's computer tomorrow to see if it is only my printer and not the program itself that is messed up. Below I've included the script with Gregg's additions and the rest of the functionality needed, although it is still horribly messy and un-optimized. In case you are curious, the error I'm getting is this: [Printers Folder] There was an error writing to LPT1: for the printer (Brother MFC3100C): There was a problem printing to the network resource. Check to make sure the printer server is working properly, and try printing again. [OK] When I change the printer to use the built-in virtual driver (BRMFC:), I get the following message: [Printers Folder] There was an error writing to BRMFC: for the printer (Brother MFC3100C): The specified path is invalid. [OK] What path? What network resource? It is a local printer connected to LPT1:. Anyway, here is the script (beware of line-wrapping). Let me know directly if you have success/failure using this script: winspool: load/library %winspool.drv kernel32: load/library %kernel32.dll print "Define GetLastError" getlasterror: make routine! [ return: [long] ] kernel32 "GetLastError" print "Define OpenPrinter" openprinter: make routine! [ "Open Printer" pprintername [string!] phprinter [char*] pdefault [integer!] return: [integer!] ] winspool "OpenPrinterA" print {Define ClosePrinter - Thanks to Gregg Irwin on REBOL list} closeprinter: make routine! [ "Close Printer" hprinter [integer!] return: [integer!] ] winspool "ClosePrinter" ; DOCINFO is used by StartDoc, and has a different structure than StartDocument, ; which the spooler uses. StartDoc is what you use for the actual printing ; commands (to a device context). The spooler uses the DOC_INFO_1 structure ; which doesn't have the size or type elements. print "Define StartDocPrinter" startdocprinter: make routine! [ "StartDocPrinter" hprinter [integer!] dwlevel [integer!] lpbdocinfo [ struct! [ ;cbsize [int] lpszdocname [string!] lpszoutput [string!] lpszdatatype [string!] ;fwtype [int] ] ] return: [integer!] ] winspool "StartDocPrinterA" print {Create a Null Buffer - Thanks to Gregg Irwin and Gabriele Santilli on REBOL list} null-buff: func [len][ head insert/dup make string! len #"^(00)" len ] print {Create Pointer Variable - Thanks again to Gregg Irwin} prin "Initial value: " probe to-binary hprinter: null-buff 4 print "Create DocInfo Struct" docinfo: make struct! [ ;cbsize [int] lpszdocname [string!] lpszoutput [string!] lpszdatatype [string!] ;fwtype [int] ] reduce ["Test Print" "" "RAW"] print "Call OpenPrinter" print either zero? ret: openprinter "Brother MFC3100C" hprinter 0 ["FAIL!"]["Success"] prin "Current value: " probe to-binary hprinter ; Have to cast the string buffer to a proper-endian integer. ; The string buffer trick is only needed for return filled (i.e. OUT) parameters. hprinter: to-integer to-binary head reverse hprinter print ["Printer handle:" hprinter] ; Don't forget, for structures that *do* have a size element, that you have to ; set it before the call. ;print "Set docinfo structure size" ;print docinfo/cbsize: length? third docinfo close-printer: does [ print "Closing Printer" print either zero? ret: closeprinter hprinter ["FAIL!"]["Success"] ] end-doc-printer: does [ print "Closing Document" print either zero? ret: enddocprinter hprinter ["FAIL!"]["Success"] ] end-page-printer: does [ print "Ending Page" print either zero? ret: endpageprinter hprinter ["FAIL!"]["Success"] ] print "Call StartDocPrinter" either zero? dwjob: startdocprinter hprinter 1 docinfo [ print ["ERROR!" getlasterror] close-printer ][print "SUCCESS!"] print "Define StartPagePrinter" startpageprinter: make routine! [ "Start Page Printer" hprinter [int] return: [int] ] winspool "StartPagePrinter" print "Define EndDocPrinter" enddocprinter: make routine! [ "End Doc Printer" hprinter [int] return: [int] ] winspool "EndDocPrinter" print "Define WritePrinter" writeprinter: make routine! [ "Write Printer" hprinter [int] lpdata [char*] dwcount [int] dwbyteswritten [int] return: [int] ] winspool "WritePrinter" print "Define EndPagePrinter" endpageprinter: make routine! [ "End Page Printer" hprinter [int] return: [int] ] winspool "EndPagePrinter" print "Call StartPagePrinter" either zero? startpageprinter hprinter [ print "FAIL!" end-doc-printer close-printer ][print "Success"] byteswritten: 0 testdata: {The quick brown fox jumped over the lazy dogs.} print "Call WritePrinter" either zero? writeprinter hprinter testdata length? testdata byteswritten [ print "FAIL!" end-page-printer end-doc-printer close-printer ][print "Success"] print "Call EndPagePrinter" either zero? endpageprinter hprinter [ print "FAIL!" end-doc-printer close-printer ][print "Success"] print "Call EndDocPrinter" either zero? enddocprinter hprinter [ print "FAIL!" close-printer ][print "Success"] close-printer if byteswritten <> length? testdata [ print "Incorrect number of bytes written!" ] halt Have fun! -Bo At 08:44 PM 7/1/02 -0600, you wrote:

Hi Bohdan, On Monday, July 01, 2002, 6:41:08 PM, you wrote: BoRL> Thanks for all the help so far. I'm hoping that someday REBOL users can BoRL> have graphical access to printers. I know it would make my applications a BoRL> lot more useful! I actually prefer emitting PDF anyway, it's more easily multiplatform... :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

Gabriele, I agree that PDF is more easily multiplatform, but sometimes you need the output to go directly to the printer without any additional human intervention. It would be nice if Acrobat could be told via an external source (like REBOL) to print the current document. Additionally, Acrobat loading on many machines is terribly slow. It would be nice if REBOL had available printer support (kind of like Python, but better). For that matter, printer page layout could use REBOL faces so you could generate the output with View or VID and then send it to the printer interface which does the conversion to the low-level printer commands.

>> printer layout/origin [image %flag.gif text "Now is the time

----- Original Message ----- From: "Bohdan or Rosemary Lechnowsky" <[amicom--sonic--net]> To: <[rebol-list--rebol--com]> Sent: Tuesday, July 02, 2002 8:30 AM Subject: [REBOL] Re: View/Pro and accessing Windows Printer API (gdi32.dll) ...

> Anyway, here is the script (beware of line-wrapping). Let me know

> if you have success/failure using this script: >

Hi Bohdan, On Tuesday, July 02, 2002, 5:33:39 PM, you wrote: BoRL> I agree that PDF is more easily multiplatform, but sometimes you need the BoRL> output to go directly to the printer without any additional human BoRL> intervention. That is absolutely true. However, users do not dislike to have a screen preview of what they are going to print. At least, this has not been a big problem to me, considering you are also giving the user the ability so send the PDF via email etc. this way. BoRL> It would be nice if Acrobat could be told via an external BoRL> source (like REBOL) to print the current document. Me and Gregg tried this using Window's ShellExecuteA; when asking to print a PDF file, with something like: win-lib: load/library %shell32.dll execute: make routine! [ hwndParent [integer!] Operation [string!] File [string!] Parameters [string!] Directory [string!] ShowCmd [integer!] return: [integer!] ] win-lib "ShellExecuteA" win-print-file: func [file [file!]] [ execute 0 "print" to-string to-local-file clean-path file "" "" 1] we got inconsistent results unfortunately. I happened to me once that win-print-file opened Acrobat and immediately sent the file to the printer (without even showing it), but the first time I tried it it only opened the file. BoRL> Additionally, Acrobat BoRL> loading on many machines is terribly slow. That is true, too. BoRL> It would be nice if REBOL had available printer support (kind of like BoRL> Python, but better). I agree, Bo. I just wanted to say that I've been able to live without it, not that I wouldn't like to have it. ;-) BoRL> Simple things should be simple to do. Yes! Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

Thanks for the report, Cyphre! Yes, I think the problem you are experiencing is due to incompatibility between Win95 and WinNT kernels. As you probably know, these are the two basic kernels all versions of Windows are built on. However, it should be possible to have the correct functions for each kernel and only call the appropriate one depending on which OS you are running. It may take a little extra work, but it shouldn't be *too* hard. :-) -Bo At 05:42 PM 7/2/02 +0200, you wrote:

Bohdan or Rosemary Lechnowsky wrote:

> Thanks for the report, Cyphre! > Yes, I think the problem you are experiencing is due to > running. It may take a little extra work, but it shouldn't be *too* > hard. :-)

Hi Bo, Here are the changes I made to get it (sort of) working here. . . . print "Define WritePrinter" writeprinter: make routine! [ "Write Printer" hprinter [int] lpdata [char*] dwcount [int] dwbyteswritten [char*] ;[int] This is another return value return: [int] ] winspool "WritePrinter" . . . byteswritten: null-buff 4 ; I had to add the form-feed here to make it flush on my laserjet. ; I'm not sure why the end-page stuff isn't doing it like I think it should. ; I could make it write to a file just fine without the form-feed. testdata: {The quick brown fox jumped over the lazy dogs.^L} print "Call WritePrinter" either zero? writeprinter hprinter testdata length? testdata byteswritten [ print "FAIL!" end-page-printer end-doc-printer close-printer ][print "Success"] byteswritten: to-integer to-binary head reverse byteswritten . . . --Gregg

Hi Bo, << It would be nice if Acrobat could be told via an external source (like REBOL) to print the current document. >> They don't make it easy, but it can be done. One catch is that it's tricky to get right because Acrobat doens't like printing silently if it's already running. << Additionally, Acrobat loading on many machines is terribly slow. >> That I don't have an answer for. :) << It would be nice if REBOL had available printer support (kind of like Python, but better). For that matter, printer page layout could use REBOL faces so you could generate the output with View or VID and then send it to the printer interface which does the conversion to the low-level printer commands. >> I've thought about this as well, but some issues with that approach are: 1) the disparity in resolution and 2) what unit of measure should be used. On the positive side, given a LAYOUT you might be able to generate output commands without too much difficulty. I think a printing dialect, that know how to deal with images, would be very nice though. --Gregg