I’m trying to improve my printing under Windows and Margins are causing issues. Is there a way to override the settings in the PrinterSettings so that the user can’t change them? I need to enforce a .33" margin for all four sides, but I don’t see a way to achieve that.
I did discover that I can’t just create an empty PrinterSetup object and then manually populate the values that I want.
With the newer releases, no. A similar kind of issue is affecting printing for @John McKernon who may have some insight as to the last usable release for forcing Windows margins to be what you need them to be. @Michel Bujardet might know too. Sorry for tagging everyone, I just don’t have the details and I think one of those two might 
Ah - that would explain why I have code to manipulate these settings in an older project (2009-ish) that was commented out.
Maybe its is the “Direct2D printing” introduced in 2017, it broke many thing. I’m still using Xojo 2016r4.1 for a windows printing program.
It used to be that you could print outside the margins on Windows, so it was a matter of calculating an offset based on the margin and then applying that to all X coordinates. I use that when we’re filling preprinted forms, so the text hits the boxes regardless of the user’s margin settings. I don’t have any experience with how that works in direct2d.
There is but not without a handle returned from the printing pipeline which is why I have this ticket in <https://xojo.com/issue/51559>
As Tim mentioned, its possible to print anywhere you want by calculating your offsets. The code in the first link on my post here has an example of printing right in the corner and at 1" increments.
Just a reminder: the problem only applies to Windows, MacOS is OK.
As far as I can tell, if you get a printer setup by opening the printer setup window, then it is impossible to print outside the margins. If you instantiate a printer setup in code (without opening the setup dialog), then you can access the entire printable area. I’m going to check out Julian’s code and see if that has a workaround.
If not, this is a HUGE problem, I’m still using Xojo 2016R3 because of this. Unfortunately, Mac apps will need to be 64 bit next year, which means using 2018R2 or later. So it looks like I could be stuck using 2016R3 for Windows and 2018R2 for Mac. So much for Xojo’s beloved cross-platform development. I’ll be back in the bad old days of using VB6 for Windows and FutureBasic for Mac, with two separate code bases. Yuck!
I just tried Julian’s code, running it from my Mac on my Windows laptop using Remote Debugger. Unfortunately, Xojo crashed after the printer dialog closed. I filed a Feedback report on that and doing further testing - the Xojo crash looks like it was a problem in displaying debug values.
Anyway, at the moment things are still looking grim.
A follow-up, Julian’s code ran without Xojo crashing, but it fails to draw lines on the page. No time to dig further now, but will look into it early next week.
It doesn’t draw lines, it draws dots, they are quite tricky to see 
There should be 4 of them.
You’re right!
I have dark floaters in my right eye, so everything looks like gnats are flying around - now that I know to look carefully, they’re the things that don’t move on the page…
Of course, if I’d looked at your code equally carefully I would’ve known what to look for.
Maybe there IS hope for printing full page, thank you!
The way that I get around this is to NOT populate the PrinterSettings object and just go straight to the Print dialog. This means that I print exactly where I want because the values are all 0. If you want to force full page, maybe that’s your answer.
You’re right, that does work, though I’ll be curious to see if there are any unforeseen ramifications.
It also makes it more difficult to do accurate print preview, though I’m sure there are ways around that, too.
Fortunately it’s not a difficult change, but it does drive me nuts that current releases of Xojo handle Windows printing differently than Mac printing, when they used to be handled the same way. Yet another set of #TargetMacOS etc. tags…