Printing problems with Windows Vista 64

[Iain Kennedy]

I am having a problem with getting my printer to work with programmes compiled under windows vista 64. My old computer ran windows XP. When I move exe files to the new computer, they work fine. When I compile the BAS files on the new computer under vista the print routines do not work.
I use the function PrinterDialog (in COMDLG32.INC) to show the printerdialog box to choose the tray, paper size and orientation. I then use DDOC printing routines to build and print the pages.
The programmes compiled under vista function correctly, show no error messages and exit. It is as though the print file is sent to the wrong port. It vanishes.
Anybody got any suggestions.

regards

Iain

[Scott Slater]

This is strange. I am using Vista-64 and have never had any problem. My suspicion is that maybe your INC files are different versions on your XP machine. Have you tried moving everything to a flash disk and running from there in both cases?

[Iain Kennedy]

Thanks for that suggestion, but it made no difference. As far as I can tell there is no change in ComDLG32.inc between the two compilers. I am beginning to wonder if there has been a change in COMDLG32.dll between XP and Vista. If they are different versions (I haven't checked yet) would I be stupid to try the old version of the dll on vista, or would that cause more problems than it is worth.

[Rodney Hicks]

Could you post compilable code showing the problem so we can all test the same code?

[Iain Kennedy]

FUNCTION ikPrinterDialog(BYVAL wHANDLE AS DWORD, PAPERORIENT AS INTEGER, PAPERSOURCE AS INTEGER) AS LONG
' PAPERORIENT is an output value, is 1 for landscape, 0 for portrait
' PAPERSOURCE is an output value,
' wHandle is window handle as input value
'function returns -1 if successful, else 0

LOCAL pdevmode AS DEVMODE PTR
LOCAL IDefsource AS INTEGER
LOCAL iprColor AS INTEGER
DIM flags AS LOCAL DWORD
DIM hhdc AS LOCAL DWORD
DIM ncopies AS LOCAL WORD
DIM nfrompage AS LOCAL WORD
DIM ntopage AS LOCAL WORD
DIM runnumber AS LOCAL LONG
DIM runname AS LOCAL STRING
LOCAL wwhandle AS DWORD

wwhandle = wHandle

flags = %PD_RETURNDC OR %PD_PRINTSETUP
a&= printerDialog(BYVAL wwHANDLE,flags,hhdc,ncopies,nfrompage,ntopage,1,1000)

IF save_hDevMode THEN
pDevMode = globallock(save_hDevMode)
aa& = @pDevmode.dmorientation
iDefSource = @pDevmode.dmDefaultSource
iPrColor = @pDevmode.dmColor

globalunlock save_hDevmode
ELSE
FUNCTION = 0
EXIT FUNCTION
END IF

IF aa& = 2 THEN
paperorient = %DDOC_LANDSCAPE
ELSE
paperorient = %DDOC_PORTRAIT
END IF
PAPERSOURCE = iDefSource
FUNCTION = -1

END FUNCTION 'ikPrinterDialog


I have used the above function to bring up the Printer selection dialog box then pass the relevant options to DDOC functions for printing. However it doesn't work under Vista 64 bit although the function returns -1.

[Michael Mattias]

>although the function returns -1.

But what does PrinterDialog() return?

a&= printerDialog(BYVAL wwHANDLE,flags,hhdc,ncopies,nfrompage,ntopage,1,10 00)

It's great that you got a& but you never test it for success/failure. For that matter, I can't find "PrinterDialog" in my SDK reference so I don't know what it is SUPPOSED to return.

There is a "PrintDlg" common dialog box which returns TRUE if the user selects "OK"

As written, your ikPrinterDialog() function will return -1 anytime save_hDevMode is true... but can't tell where 'save_devMode' comes from. (some GLOBAL set somewhere?)

MCM
PS: when posting code please use Code Tags (The little "BB Code" link on the lower part of the screen).

[Iain Kennedy]

Michael, as I said above, PrinterDialog is in ComDlg32.inc.
My function IkPrinterDialog is lifted from a function that I copied from a post many years ago (I don't remember the author). It has worked for many years. I agree my code should test for a&.
Iain

[Michael Mattias]

Ok I found that function- it's just a wrapper for PrintDlg. So what does PrinterDialog return? (it returns TRUE if user clickedOK).

Re-reading the problem.... maybe your problem is not in this function at all... it may be at the point of printing (dpEndDoc or however you are doing it).

If all your values are "good" in ikPrintDialog, then the problem is NOT here. Are they good?

If they are good, without seeing the actual call to print there's no telling where your problem really is.

MCM

[Iain Kennedy]

Thanks for that. I've done a bit more digging. XPRINT GET DC returns 0, implying that there is no printer attached.
My dell printer is attached to USB001 port by a bluetooth connection so no printer is connected to LPT1 etc. Could this be the problem.

regards

Iain

[Michael Mattias]

I don't know XPRINT all that well, but I can RTFM:

Purpose
Retrieve the handle of the device context (DC) for the host printer page.

Syntax
XPRINT GET DC TO hDC???

Remarks
If no host printer is currently attached, zero is returned.

But I have no clue what you are doing mixing DDOC calls with XPRINT calls (code not shown). DDOC handles all this stuff itself. So does XPRINT. Pick one.

Since Brett Favre entered one of his annual "I've decided for now" phases yesterday, he should be available to take your call and together you can share a good waffle.


MCM

[Iain Kennedy]

I am not mixing XPRINT with DDOC, simply a small test programme to try and find a solution to my problem. Can anybody comment on the fact that my printer is connected to a USB port.
What do you mean by RTFM?

[Michael Mattias]

>What do you mean by RTFM?

It's an acronym. That fact plus Google(r) ought to get you a meaning.

You should probably learn this soon. It's important enough to programming that this board even has a 'smiley' for it.


MCM