PrintDocument PrintPage event
-
Hi When previewing a document using the PrintDocument class: when i receive a PrintPage event, how can I tell if it's for printing on the screen or the printer? I want a slightly different output when printing to the printer. Thanks
No, because the whole idea of a print preview is to preview what will be printed! Why would you do anything different? Not only does it not make sense, it inconsistent with every other program your users will use. If you really must, you'll have to keep some boolean flag or something similar. Your app should know when the Print and Print Preview buttons were clicked (or whatever you use) so you can determine what to draw based on the state of that flag. In any case, there's just really no good way to tell based on the
PrintPageEventArgs, or thePrintEventArgsfor that matter. The properties would be the same for both screen and print, since theGraphicsobject is supposed to be created to match the printer on which thePrintDocumentwill be printed (i.e., scaling, twips, etc.).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
No, because the whole idea of a print preview is to preview what will be printed! Why would you do anything different? Not only does it not make sense, it inconsistent with every other program your users will use. If you really must, you'll have to keep some boolean flag or something similar. Your app should know when the Print and Print Preview buttons were clicked (or whatever you use) so you can determine what to draw based on the state of that flag. In any case, there's just really no good way to tell based on the
PrintPageEventArgs, or thePrintEventArgsfor that matter. The properties would be the same for both screen and print, since theGraphicsobject is supposed to be created to match the printer on which thePrintDocumentwill be printed (i.e., scaling, twips, etc.).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Do not presume to know the mind of someone asking an apparently stupid question. There is a school of thought that says that there are no stupid questions, only stupid answers. I beg to differ about: - there being no good reason to act differently. - there being no good way to tell the difference. Now, why would I want Print Preview to be different? Because my graphics lines @ 1200 dpi are TOO THIN to show even at 500% Zoom ! So I want to use thicker lines in print preview (and it's also quicker generating a page of bitmapped graphics @ 200dpi rather than 1200dpi). I don't like flags. The idea of OO stuff is encapsulation. Good News: The PrintDocument passed as object sender to XX_PrintPage contains a member 'PrintController' which has a member 'underlyingController' which has a type of {System.Drawing.Printing.PreviewPrintController} or {System.Drawing.Printing.StandardPrintController}. Bad News: This is supposed to be hidden from you (thank you Bill and your people who can't think outside the square and mutter "Why would you do anything different"). Good News: Use Reflection! //using System.Reflection; PrintDocument PD = sender as PrintDocument; PrintControllerWithStatusDialog PC = PD.PrintController as PrintControllerWithStatusDialog; FieldInfo FI = PC.GetType().GetField("underlyingController", BindingFlags.NonPublic | BindingFlags.Instance); PreviewPrintController PPC = FI.GetValue(PC) as PreviewPrintController; Now, if PPC is not null, it's PrintPreview. If PPC is null, it's not PrintPreview. Bad News: It's ugly, brittle, hardly polymorphic, uses undocumented features of dotNet Framework and might stop working in a future release. Maybe it's not a good way, but it's better than no way. Good News: It works for me, and I hope it does for you, too. Regards Brewman
-
Do not presume to know the mind of someone asking an apparently stupid question. There is a school of thought that says that there are no stupid questions, only stupid answers. I beg to differ about: - there being no good reason to act differently. - there being no good way to tell the difference. Now, why would I want Print Preview to be different? Because my graphics lines @ 1200 dpi are TOO THIN to show even at 500% Zoom ! So I want to use thicker lines in print preview (and it's also quicker generating a page of bitmapped graphics @ 200dpi rather than 1200dpi). I don't like flags. The idea of OO stuff is encapsulation. Good News: The PrintDocument passed as object sender to XX_PrintPage contains a member 'PrintController' which has a member 'underlyingController' which has a type of {System.Drawing.Printing.PreviewPrintController} or {System.Drawing.Printing.StandardPrintController}. Bad News: This is supposed to be hidden from you (thank you Bill and your people who can't think outside the square and mutter "Why would you do anything different"). Good News: Use Reflection! //using System.Reflection; PrintDocument PD = sender as PrintDocument; PrintControllerWithStatusDialog PC = PD.PrintController as PrintControllerWithStatusDialog; FieldInfo FI = PC.GetType().GetField("underlyingController", BindingFlags.NonPublic | BindingFlags.Instance); PreviewPrintController PPC = FI.GetValue(PC) as PreviewPrintController; Now, if PPC is not null, it's PrintPreview. If PPC is null, it's not PrintPreview. Bad News: It's ugly, brittle, hardly polymorphic, uses undocumented features of dotNet Framework and might stop working in a future release. Maybe it's not a good way, but it's better than no way. Good News: It works for me, and I hope it does for you, too. Regards Brewman
-
Do not presume to know the mind of someone asking an apparently stupid question. There is a school of thought that says that there are no stupid questions, only stupid answers. I beg to differ about: - there being no good reason to act differently. - there being no good way to tell the difference. Now, why would I want Print Preview to be different? Because my graphics lines @ 1200 dpi are TOO THIN to show even at 500% Zoom ! So I want to use thicker lines in print preview (and it's also quicker generating a page of bitmapped graphics @ 200dpi rather than 1200dpi). I don't like flags. The idea of OO stuff is encapsulation. Good News: The PrintDocument passed as object sender to XX_PrintPage contains a member 'PrintController' which has a member 'underlyingController' which has a type of {System.Drawing.Printing.PreviewPrintController} or {System.Drawing.Printing.StandardPrintController}. Bad News: This is supposed to be hidden from you (thank you Bill and your people who can't think outside the square and mutter "Why would you do anything different"). Good News: Use Reflection! //using System.Reflection; PrintDocument PD = sender as PrintDocument; PrintControllerWithStatusDialog PC = PD.PrintController as PrintControllerWithStatusDialog; FieldInfo FI = PC.GetType().GetField("underlyingController", BindingFlags.NonPublic | BindingFlags.Instance); PreviewPrintController PPC = FI.GetValue(PC) as PreviewPrintController; Now, if PPC is not null, it's PrintPreview. If PPC is null, it's not PrintPreview. Bad News: It's ugly, brittle, hardly polymorphic, uses undocumented features of dotNet Framework and might stop working in a future release. Maybe it's not a good way, but it's better than no way. Good News: It works for me, and I hope it does for you, too. Regards Brewman
Bryan White wrote: There is a school of thought that says that there are no stupid questions, only stupid answers. ...and this would be a stupid school to attend. There is stupid questions, and I never said that this original question was stupid. Stupid questions are ones that we get in this - and every other forum - on a somewhat regular basis, like "What does method X do?" This question could easily be answered by simply typing it in the index of your help system, either the MSDN Library that is installed (or through an MSDN Library subscription or higher), or with MSDN Online. It's not so much that the question itself is stupid, just that asking it is stupid because developers should at least be able to answer such simple questions for themselves. Bryan White wrote: I don't like flags. The idea of OO stuff is encapsulation. Is there any reason that part of such encapsulation is not using some sort of state flags? MANY of the implementations in the class library - especially those that wrap the Windows Common Controls - use state flags / variables and act accordingly. It's just part of the encapsulation. As far as the rest of your reply goes, you have discovered a much better way of determining the output device. While reflection can often times be ugly, it many cases it is necessary. Kudos! :)
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
Bryan White wrote: There is a school of thought that says that there are no stupid questions, only stupid answers. ...and this would be a stupid school to attend. There is stupid questions, and I never said that this original question was stupid. Stupid questions are ones that we get in this - and every other forum - on a somewhat regular basis, like "What does method X do?" This question could easily be answered by simply typing it in the index of your help system, either the MSDN Library that is installed (or through an MSDN Library subscription or higher), or with MSDN Online. It's not so much that the question itself is stupid, just that asking it is stupid because developers should at least be able to answer such simple questions for themselves. Bryan White wrote: I don't like flags. The idea of OO stuff is encapsulation. Is there any reason that part of such encapsulation is not using some sort of state flags? MANY of the implementations in the class library - especially those that wrap the Windows Common Controls - use state flags / variables and act accordingly. It's just part of the encapsulation. As far as the rest of your reply goes, you have discovered a much better way of determining the output device. While reflection can often times be ugly, it many cases it is necessary. Kudos! :)
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
You wrote " Bryan White wrote: I don't like flags. The idea of OO stuff is encapsulation. Is there any reason that part of such encapsulation is not using some sort of state flags? MANY of the implementations in the class library - especially those that wrap the Windows Common Controls - use state flags / variables and act accordingly. It's just part of the encapsulation. " I have no problem with flags describing an objects INTERNAL state. You are correct, and I agree. I should probably have said "I don't like flags holding the state of, or describing, OTHER objects". This is hinted at by my following sentence (encapsulation). If (as in this case) an object(PrintDocument) is being activated from another one(either PreviewPrintController/PrintPreviewDialog or StandardPrintController/PrintDialog), then rather than storing a flag about which one activated it (and causing headaches if you decide Preview = !Standard and a third one is added), I feel that it is better to just store the controller/dialog object as a 'parent object'. Then, Microsoft decided to specifically hide this 'parent object', which I find VERY FRUSTRATING (as you can probably guess from the tone of my earlier response. BTW my own technique for defining an item as "this is public but you probably shouldn't be using it" is to prefix the name with an underscore "_". This may not be part of any standard, but hopefully makes people (and myself in a week's time!) think twice before using it.) If this hidden member did not exist, then rather than create a flag I would still prefer to: - create a derived class from PrintDocument (called PrintDocumentWithActivator?) with a member of type object called something like 'parent' or 'activator'. - store the PrintPreviewDialog(or other activator) object in it - test this object in the PrintPage event. I feel that this follows the Open-Closed Principle(OCP) better than a flag. Once the 'activator' object is defined, there need be no further changes in the class if, say, a PrintTo3DEngraverDialog came along later, and the programmer wanted a registered trade mark engraved bottom left rather than a copyright notice printed bottom right. If the flag was held in the app class, then it would be impossible to decide to how to print the PrintDocument object by just referring to that particular instance; you would need TWO objects to decide (difficult when just one object is passed in an event handler), and in danger of violating the Dependency Inversion Principle(DIP); why should the app know or
-
You wrote " Bryan White wrote: I don't like flags. The idea of OO stuff is encapsulation. Is there any reason that part of such encapsulation is not using some sort of state flags? MANY of the implementations in the class library - especially those that wrap the Windows Common Controls - use state flags / variables and act accordingly. It's just part of the encapsulation. " I have no problem with flags describing an objects INTERNAL state. You are correct, and I agree. I should probably have said "I don't like flags holding the state of, or describing, OTHER objects". This is hinted at by my following sentence (encapsulation). If (as in this case) an object(PrintDocument) is being activated from another one(either PreviewPrintController/PrintPreviewDialog or StandardPrintController/PrintDialog), then rather than storing a flag about which one activated it (and causing headaches if you decide Preview = !Standard and a third one is added), I feel that it is better to just store the controller/dialog object as a 'parent object'. Then, Microsoft decided to specifically hide this 'parent object', which I find VERY FRUSTRATING (as you can probably guess from the tone of my earlier response. BTW my own technique for defining an item as "this is public but you probably shouldn't be using it" is to prefix the name with an underscore "_". This may not be part of any standard, but hopefully makes people (and myself in a week's time!) think twice before using it.) If this hidden member did not exist, then rather than create a flag I would still prefer to: - create a derived class from PrintDocument (called PrintDocumentWithActivator?) with a member of type object called something like 'parent' or 'activator'. - store the PrintPreviewDialog(or other activator) object in it - test this object in the PrintPage event. I feel that this follows the Open-Closed Principle(OCP) better than a flag. Once the 'activator' object is defined, there need be no further changes in the class if, say, a PrintTo3DEngraverDialog came along later, and the programmer wanted a registered trade mark engraved bottom left rather than a copyright notice printed bottom right. If the flag was held in the app class, then it would be impossible to decide to how to print the PrintDocument object by just referring to that particular instance; you would need TWO objects to decide (difficult when just one object is passed in an event handler), and in danger of violating the Dependency Inversion Principle(DIP); why should the app know or
I never said it was a good way! :) I agree with you that it isn't good for determining the state of other objects, but it was just a quick and dirty idea that could work if managed correctly (i.e., good synchronization and exception handling). As I was helping someone else with a similar problem (actually, it might've been the same guy), I did find a way to determine which controller is being used without resorting to reflection. The
PrintDocumentclass has aPrintControllerproperty. This could be used in the event handlers (or inOn_EventName_methods if you encapsulate thePrintDocument) to determine whichPrintController- like thePreviewPrintController- is being used as the output device.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----