error msg?

[MichaelW]

Okay.  The call should be set up to succeed.  Make sure the buffer is large enough and that you use valid pointers.  The INFO_4 structure is 12 bytes per device.  Two ptrs and an attributes dword.

The size would be 12 bytes in 64-bit code?

[satpro]

Good catch, and no it wouldn't, but we were talking 32-bit code.

[shankle]

Hi Satpro,
Thank you for replying.
Don't misunderstand me I am not blaming GoAsm for my inadequacies.
I have incorporated your suggestions and still no luck as you can see below.
I don't use macros either as I hate to dig all over the place to find out what
they need or mean. Same with includes. Only when necessary.

The next 3 lines are a quote from the Microsoft CreateDC API.
lpszDriver
"A pointer to a null-terminated character string that specifies either DISPLAY or the name
of a specific display device. For printing, we recommend that you pass NULL to lpszDriver
because GDI ignores lpszDriver for printer devices".

Enumprinter 2 puts garbage in parmeter 4 which is PrinterCString.
Therefor CreatDC does not work.

.data
dwNeeded         dd  0
dwReturned       dd  0
PrintCString       db   96 DUP 0    ; buffer to receive the printer name
winspoolstring   db   "WINSPOOL",0

.code
; other code

WndProc:
        FRAME hWnd,iMsg,wParam,lParam
        USES ebx,edi,esi
        Local hMemory,hdc,hdcPrn

;.WM_CREATE
        cmp D[iMsg],WM_CREATE 
        jne >>.WM_CHAR
        invoke  EnumPrinters, PRINTER_ENUM_LOCAL,NULL,4,NULL,\
                0,addr dwNeeded,addr dwReturned
       invoke  GlobalAlloc, GHND,[dwNeeded]
       mov       [hMemory], eax
       invoke  GlobalLock, eax   
        invoke  EnumPrinters, PRINTER_ENUM_LOCAL,NULL,4,addr PrintCString,\
                                [dwNeeded],addr dwNeeded,addr dwReturned                               
                                       
;   test begin
;tm2              db   'got to WM_CREATE',0
      pushad
      invoke MessageBox, NULL,addr TM2,addr PrintCString,MB_OK     
     popad     
;   test end
;The result of this test shows "yo@" with a tilder over the "o" in PrintCString.
;So good data is not getting into PrintCSring even though EnumPrinter is not
; failing. Of course this causes CreatDC to also fail.

        mov ebx,addr PrintCString
        invoke  CreateDC, addr winspoolstring,[ebx+PRINTER_INFO_4.pPrinterName],NULL,NULL
       mov       [hdcPrn],eax
       invoke  GlobalUnlock, [hMemory]   
       invoke  GlobalFree, [hMemory]   
                         
       endf

[satpro]

Shankle,

I've read that about WINSPOOL, too.  The book I use for reference is the Windows 2000 API SuperBible and it makes a distinction between Win95/98 and 2000, which is more like today's OS.  It talks about WINSPOOL.  Maybe I'm mis-reading something there.

But I'll look into it today.


P.S.  Did you try the suggestion about using the ptrs on the first call to EnumPrinters?  Oh--if you're getting info on 6 devices (72 bytes) the first array in PrintCString might not be what you're looking for--just a guess.  The rest would offset by 12.  You are compiling Win32 and for Ansi chars, right?

[satpro]

Shankle,
After writing the last post to you I got to thinking.  You know, I feel like I'm just throwing guesses out there without knowing what I should know to actually help.  At the very least it's unfair to you.  At it's worst I look stupid for throwing out guesses.  There is just this small bit of visible code to go on that tells very little about the actual program.

How about this?  Zip up your GoAsm folder and email it to me.  I promise no judgments on coding style or any of that.  I have this console "debugger" I wrote that tells me variables, flags, etc.  I use it a lot for tricky new stuff.  On top of that I bought the paid version of GoBug so I really will find the cause of this trouble.  But doing it this way now is getting all of us nowhere fast.

My idea is to isolate the Enum stuff and throw it into the console, and actually work with your code.  It probably won't take forever to find the answer.

You don't have to do that, but I think any more guessing is just "poking and hoping."

Bert

[shankle]

Hi Satpro,
I have only 1 printer(HP Officejet Pro l7580).
Yes it is ANSI.
I don't mind the suggestions and I do try to test them.
I understand the problem of trying to help someone with your hands tied.
However IMHO the other parts of the program have nothing to do with
the EnumPrinters, CreateDC, GetDefaultPrinter, PrintDlgEX. All of which don't
work for me.

[wjr]

As mentioned, with the corrections, your second call to EnumPrinters works just fine. Your PrintCString buffer gets filled with PRINTER_INFO_4 structures. To see this, correct your test as follows:

Code Select Expand

invoke MessageBox, NULL,addr TM2,[PrintCString],MB_OK
invoke MessageBox, NULL,addr TM2,[PrintCString+12],MB_OK
invoke MessageBox, NULL,addr TM2,[PrintCString+24],MB_OK
invoke MessageBox, NULL,addr TM2,[PrintCString+36],MB_OK
invoke MessageBox, NULL,addr TM2,[PrintCString+48],MB_OK
invoke MessageBox, NULL,addr TM2,[PrintCString+60],MB_OK

It seems like your call to CreateDC may require a pointer to a DEVMODE structure as the last argument (perhaps the 64-bit drivers are more picky if this was previously working on 32-bit).

I went a slightly different route with:
GetDefaultPrinter
OpenPrinter
DocumentProperties ;to get size of buffer for DEVMODE
GetProcessHeap
HeapAlloc
DocumentProperties
CreateDC

I did get this to work up to this point. However, for some reason ONLY while debugging, the first call to DocumentProperties fails. Searching the web, there does appear to be some difficulties with this function, as well as PrintDlgEx, on more recent 64-bit OS's.

[shankle]

Thank you WJR,
I'm still working on the 32-bit version.
Haven't started to worry about the 64-bit code.
The 2nd EnumPrinter is now working correctly.
I can see my printer in the test messagebox.
So now the problem has moved to the "CREATEDC" api.

[shankle]

More fun.
The 1st window is written to the screen for me to enter data for the program.
Then this wonderful Windows message appears: "program has stopped working".
I never get a chance to enter the data that's needed. Yes, I have probably screwed
up GoAsm or Windows or both somehow. Therefor wParam never gets loaded
with the keyed input before the Error message appears.

[Yuri]

I suggest you run your program in a debugger. E.g. the freeware OllyDbg. This way you will see the offending command.

[shankle]

I have shown below what happens in GoBUG at  the end of WM_PAINT after the
1st screen  is created. It shows the screen and then a Windows message is
presented " the program has ceased to function".  ".doneh" is at the very end
of WM_PAINT. If I insert a message box right after ".doneh", it lets me enter
my data and fails again for other reasons. This is my 1st attempt with Go Bug.
;------------------------------------------------------------------------
                 GoBug - copyright Jeremy Gordon 1996-2009
                Date: Sunday, August 12, 2012 Time: 11:51:18 AM
                                Dump of codepane

    ~~~WndProc.doneh:~~~>
    4045E4: PUSH EBP
    4045E5: ADD D[ESP],-54
    4045E9: PUSH [EBP+14]
    4045EC: CALL EndPaint(USER32.dll)
    4045F1: MOV ESP,EBP
    4045F3: POP ESI
    4045F4: POP EDI
    4045F5: POP EBX
    4045F6: POP EBP
    4045F7: RET 10   
    ~~~WndProc.WM_DESTROY:~~~>
    4045FA: CMP D[EBP+18],2
    4045FE: JNZ >404608
    404600: PUSH [EBP+20]
    404603: CALL PostQuitMessage(USER32.dll)   
    ~~~WndProc.default:~~~>
    404608: PUSH [EBP+20]
    40460B: PUSH [EBP+1C]
    40460E: PUSH [EBP+18]
    404611: PUSH [EBP+14]
    404614: CALL DefWindowProcA(USER32.dll)
    404619: MOV ESP,EBP
    40461B: POP ESI
    40461C: POP EDI
    40461D: POP EBX
    40461E: POP EBP
    40461F: RET 10
   

[dedndave]

Code Select Expand

    4045E4: PUSH EBP
    4045E5: ADD D[ESP],-54
    4045E9: PUSH [EBP+14]
    4045EC: CALL EndPaint(USER32.dll)
    4045F1: MOV ESP,EBP
    4045F3: POP ESI
    4045F4: POP EDI
    4045F5: POP EBX
    4045F6: POP EBP
    4045F7: RET 10

there must be more to it than that   :P
the stack frame looks a little strange, there
we don't see the call to BeginPaint, nor the initialization of the stack frame
or - maybe that's it - lol
the sub 54h sounds like it might be making space for a PAINTSTRUCT

Jack...
i have repeatedly mentioned that you might post the full source
we have a hard time doing much in bits and pieces
it's like putting together a jigsaw puzzle with only 10% of the pieces