Default Printer - after all this time..

Xojo prints to the default printer.
If you display a printer setup dialog, the best you can do is change the paper size.

This isnt ‘the best’.

But recently I have struggled with the default printer setting in my Windows VM
It was Windows 7 , in which I had a PDF printer driver, a few HP printers, and a Brother QL label printer whose page sizes range from miniscule to beermat.
Setting the HP printer to be default lasted about 3 minutes… even during the time it took to launch Xojo, Windows had switched back to the QL
Deleting the printer didnt help… 2 minutes later it came back by itself, and became the default printer.
Deleted drivers, disabled the printer, hacked the registry… none of it made any difference… the QL kept going back to default

So, in case this happens to anyone else, the cause was the Mac which hosted the VM.

Even though the printers were not set to be ‘shared’, the QL was the default printer on the Mac, and that VMWare session blindly duplicated it into Windows at every opportunity. I had to kill it on the Mac to test printing on A4 inside the VM.

But I’d still like a dialog that allows me to choose which printer I want to print to, regardless which one is the default.

Use the OpenPrinterDialog after PrinterSetupDialog to allow the user to select a different printer.

a/ oh, there is one?
b/ this sounds back to front - choose the paper size and then choose the printer?
If the default printer is a label printer (as above) you cannot choose A4
But I’ll give it a try. Thanks Tim

[quote=403315:@Jeff Tullin]a/ oh, there is one?
b/ this sounds back to front - choose the paper size and then choose the printer?
If the default printer is a label printer (as above) you cannot choose A4
But I’ll give it a try. Thanks Tim[/quote]

The problem is that looking at it from the printer’s side is what is back to front:

Paper Size is a property of the document, not the printer. The printer controls output and the program decides how to map the document size property to the printer limitations in the print dialog (fit, stretch, crop, etc.).

If a program will print to envelopes, it should know about envelopes, regardless of the printer that ends up being used.

This is similar to how size is a property of an image, not of the monitor it will be displayed in.

I don’t get that .
It makes sense for a PDF which has a life independant of the printed page.

But if you choose a different page size / printer when using Word for example, the on screen document properties change… the document changes shape to match the printer, not the other way round.

[quote=403445:@Jeff Tullin]I don’t get that .
It makes sense for a PDF which has a life independant of the printed page.

But if you choose a different page size / printer when using Word for example, the on screen document properties change… the document changes shape to match the printer, not the other way round.[/quote]

No. The document size is always a property of the document. When you change it in the print dialog you’re changing the document properties. if you send that document to me, it’ll have the same page size you set.

Setting it in the print dialog is only a shortcut to the page setup, but it’s still modifying the document to fit the size before it is sent to the printer.

I do understand your logic, and obviously having a paper size in a document is a factor of the document format you adopt. Document formats where printing is important have the size as a property. Document formats where the paper size is irrelevant still have the paper size applied to them before printing, and the program needs to be able to manage the necessary layout changes if needed, before sending to the printer.

If you make labels or other documents where layout changes when resizing is important you may wish to set a format for which you have no printer. If you make documents where resizing is just a matter of “fitting” then it’s a lot simpler, since you resize on the fly as needed (but the size and resizing logic are still applied to the document in full before sending to the printer)

For me, I need to know

  • the size of the paper in points
  • the dpi
    because I want to
    -print rows at an accurate size on the paper, and
    -know how many rows I can fit on the paper

Its a different approach to getting stuff onto paper.
So ‘make an A4 sized graphic and squeeze it onto letter or A5 or whatever’ doesnt work for me.

I need to print things at the same physical size on Letter, A4 , A5 or A1
And print more rows on A4 than I do on A5

If the default printer is A4 and I don’t ‘get’ a new printer before the print preview stage, guessing at A4 sizes gives reasonable figures.

But in this case, my bully of a Mac was forcing the default printer to be a label printer, with a page size of 62 x 38 mm, giving ludicrous page count ‘estimates’ ( in the hundreds of pages).
Without the OpenPrinterDialog, I could not even change that to be a different printer, and was faced with a selection of similar small page areas.

I agree, it’s not ideal. And it does seem backwards, but Xojo was forced into it by the way Microsoft changed the dialogs. I save the setupstring, so the next time, the printer is already selected and the user can dial in the margins, paper tray, etc. It’s a pain the first couple of times, but then they pretty much forget about it.

[quote=403599:@Jeff Tullin]I need to print things at the same physical size on Letter, A4 , A5 or A1
And print more rows on A4 than I do on A5

[/quote]

I don’t understand. These are standard sizes. You don’t need what the printer supports to know how to layout the printed document. You can choose the correct one at print time.

If you want to display the proper paper size onscreen I would understand, but if it’s only printing you can render to the correct size on the fly and present to print preview and to the printer according to the right size.

If you want to display onscreen to a pre-defined paper size the way it would print then it’s a problem, but you can ask the user to select a paper size and remember the last choice for the printer.

I know.

The original point of this post is that the printer kept getting forced to one I didn’t want.
I posted it in case anyone else ran into that situation, and then got sidetracked.

OpenPrinterDialog (even if I don’t immediately use the returned graphic) gets much of what I want.

There’s a declare that will cancel the print job so you can throw away the result of OpenPrinterDialog and not shoot out a blank sheet of paper. I can dig that up if you want it.

Its been a long time but I think that’s the reason why I didn’t use this method from way back.
That would be very helpful Tim.

Here’s what I have, but I see this is GDI, not Direct2D. I haven’t embraced the new drawing mechanism yet.

  dim hdc as integer
  dim g as graphics
  dim ps as PrinterSetup

  declare function AbortDoc lib "gdi32" (hDC as integer) as integer
  
  ps = RestorePrinterSetup
  g = OpenPrinterDialog(ps)
  if g= nil then return
  
  hdc= g.Handle(Graphics.HandleTypeHDC)
  call AbortDoc(hdc)

No need to be flip :slight_smile: I was trying to understand, since while I have never found this issue I may find it in the future and I’d like to have an option ready.

I’ve seen Tim’s response. Ironically seeing how to avoid the issue helped me understand what the issue was.