Open mdell-seradex opened 1 year ago
@mdell-seradex That's a good question. It will probably involve some digging. I'll ping some folks.
@dotnet/dotnet-winforms Can someone answer this question?
Is there no way to apply that setting via code?
The app compat switch value is cached on the first access and is backed up by a static field. You have to set it the first thing on app start up. https://learn.microsoft.com/en-us/dotnet/api/system.appcontext.setswitch?view=netframework-4.8.1 I had not experimented with this value though.
It seems that the document does not mention any drawback to this
Drawback is a potential, though unlikely, compatibility break in case the app depended on reading printer data for every page.
For other questions I would need to look up sources, will come back later.
I believe it would be more accurate to say that the optimization is not applied if page settings are modified, not printer settings.
I see the root of the confusion here. Either way is accurate. The optimization is skipped when the "PageSettings" object is modified and that change is applied to the printer DevMod here - https://referencesource.microsoft.com/#System.Drawing/commonui/System/Drawing/Printing/PageSettings.cs,335 by calling https://learn.microsoft.com/en-us/windows/win32/printdocs/documentproperties.
If an app was compiled targeting 4.5.2, but is run on a machine that has 4.8.1 installed, then what setting should be used?
For application running on frameworks newer than 4.5.2, and 4.5.2 is out of support, so now this shouls always be the case, (no matter what the target framework is), use Switch.System.Drawing.Printing.OptimizePrintPreview app.config switch. The appSettings value had been removed from the codebase.
I take it then that the app's target framework is irrelevant, at least in this case. The installed framework version is what matters.
Also, I suppose that one could say that the optimization is skipped when "modifying the print settings via the PageSettings object", "modifying the PageSettings object which controls the print settings", or something similar. Thank you for the clarification.
I take it then that the app's target framework is irrelevant, at least in this case. The installed framework version is what matters.
yes
"modifying the PageSettings object which controls the print settings"
Maybe this is more accurate, but it crosses into the area where it's best to read source code to see exactly what happens, how PageSettings object control the "printer". I see the doc as an introduction to the feature.
Adding to Dec sprint as a reminder to read through this and see what doc work is involved in addressing this issue.
The document states that if OptimizePrintPreview/EnablePrintPreviewOptimization is set to true, performance can be increased when using network printers or printer preferences are modified.
It seems that the document does not mention any drawback to this. If there are none, then why would anyone want this optimization to be disabled?
Also, it has the following restriction:
Looking at the reference source code PrintController.PrintLoopOptimized (referencesource), and comparing it to the PrintLoop method just above it, I believe it would be more accurate to say that the optimization is not applied if page settings are modified, not printer settings. Perhaps there are other things using it that I did not find.
Also, it states that
apps running on the .NET Framework 4.5.2
must use theEnablePrintPreviewOptimization
setting, but when running on.NET Framework 4.6 or later versions
, you can use the other version of the setting (OptimizePrintPreview
). It almost makes it sound like the older setting would still work. Most systems likely have .NET Framework 4.8.1 installed on them by now. If an app was compiled targeting 4.5.2, but is run on a machine that has 4.8.1 installed, then what setting should be used?\ (Fixed in #1558)Is there no way to apply that setting via code? Digging through the .NET reference source, it appears that is may not be possible. I do see that if System.AppContext is used, it might be, but I have not found when that might be the case. Perhaps because my application is targetting 4.5.2, I do not have access to System.AppContext, as it only applies to .NET Framework 4.6 and above. We are currently working on moving to 4.8.1 as we have third party components that must be updated.
I greatly appreciate any feedback on this.
Thank you.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.