Troubleshoot why PrintWindow is blank
up vote
1
down vote
favorite
I am trying to capture screenshot of inactive window with PrintWindow. It works correctly for calculator and for capturing Google Chrome, but for some other applications, like games, it saves white area.
What could be the reasons for PrintWindow to fail and how to validate them?
EDIT: I want tool to report why window can not be captured
winapi screenshot
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
|
show 1 more comment
up vote
1
down vote
favorite
I am trying to capture screenshot of inactive window with PrintWindow. It works correctly for calculator and for capturing Google Chrome, but for some other applications, like games, it saves white area.
What could be the reasons for PrintWindow to fail and how to validate them?
EDIT: I want tool to report why window can not be captured
winapi screenshot
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
stackoverflow.com/questions/25500137/…
– CodeCaster
Jun 6 '15 at 12:09
@CodeCaster it is not about full screen, but thanks for the pointer.
– anatoly techtonik
Jun 6 '15 at 12:18
@CodeCaster your linked question is about how to get screenshot of desktop. desktop appeared blank, because its content was rendered in a child window. I tried to get children of my app window, but EnumChildWindows failed for it.
– anatoly techtonik
Jun 6 '15 at 12:53
The application is Adobe Air app with ApolloRuntimeContentWindow class.
– anatoly techtonik
Jun 6 '15 at 13:03
Windows have to supportPrintWindowand not all of them do.
– Jonathan Potter
Jun 6 '15 at 21:03
|
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am trying to capture screenshot of inactive window with PrintWindow. It works correctly for calculator and for capturing Google Chrome, but for some other applications, like games, it saves white area.
What could be the reasons for PrintWindow to fail and how to validate them?
EDIT: I want tool to report why window can not be captured
winapi screenshot
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
I am trying to capture screenshot of inactive window with PrintWindow. It works correctly for calculator and for capturing Google Chrome, but for some other applications, like games, it saves white area.
What could be the reasons for PrintWindow to fail and how to validate them?
EDIT: I want tool to report why window can not be captured
winapi screenshot
winapi screenshot
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
edited Jun 6 '15 at 12:20
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
asked Jun 6 '15 at 11:25
anatoly techtonik
11.6k58299
11.6k58299
stackoverflow.com/questions/25500137/…
– CodeCaster
Jun 6 '15 at 12:09
@CodeCaster it is not about full screen, but thanks for the pointer.
– anatoly techtonik
Jun 6 '15 at 12:18
@CodeCaster your linked question is about how to get screenshot of desktop. desktop appeared blank, because its content was rendered in a child window. I tried to get children of my app window, but EnumChildWindows failed for it.
– anatoly techtonik
Jun 6 '15 at 12:53
The application is Adobe Air app with ApolloRuntimeContentWindow class.
– anatoly techtonik
Jun 6 '15 at 13:03
Windows have to supportPrintWindowand not all of them do.
– Jonathan Potter
Jun 6 '15 at 21:03
|
show 1 more comment
stackoverflow.com/questions/25500137/…
– CodeCaster
Jun 6 '15 at 12:09
@CodeCaster it is not about full screen, but thanks for the pointer.
– anatoly techtonik
Jun 6 '15 at 12:18
@CodeCaster your linked question is about how to get screenshot of desktop. desktop appeared blank, because its content was rendered in a child window. I tried to get children of my app window, but EnumChildWindows failed for it.
– anatoly techtonik
Jun 6 '15 at 12:53
The application is Adobe Air app with ApolloRuntimeContentWindow class.
– anatoly techtonik
Jun 6 '15 at 13:03
Windows have to supportPrintWindowand not all of them do.
– Jonathan Potter
Jun 6 '15 at 21:03
stackoverflow.com/questions/25500137/…
– CodeCaster
Jun 6 '15 at 12:09
stackoverflow.com/questions/25500137/…
– CodeCaster
Jun 6 '15 at 12:09
@CodeCaster it is not about full screen, but thanks for the pointer.
– anatoly techtonik
Jun 6 '15 at 12:18
@CodeCaster it is not about full screen, but thanks for the pointer.
– anatoly techtonik
Jun 6 '15 at 12:18
@CodeCaster your linked question is about how to get screenshot of desktop. desktop appeared blank, because its content was rendered in a child window. I tried to get children of my app window, but EnumChildWindows failed for it.
– anatoly techtonik
Jun 6 '15 at 12:53
@CodeCaster your linked question is about how to get screenshot of desktop. desktop appeared blank, because its content was rendered in a child window. I tried to get children of my app window, but EnumChildWindows failed for it.
– anatoly techtonik
Jun 6 '15 at 12:53
The application is Adobe Air app with ApolloRuntimeContentWindow class.
– anatoly techtonik
Jun 6 '15 at 13:03
The application is Adobe Air app with ApolloRuntimeContentWindow class.
– anatoly techtonik
Jun 6 '15 at 13:03
Windows have to support
PrintWindow and not all of them do.– Jonathan Potter
Jun 6 '15 at 21:03
Windows have to support
PrintWindow and not all of them do.– Jonathan Potter
Jun 6 '15 at 21:03
|
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
Every window has a default implementation for WM_PRINT, you will use it if you call PrintWindow() and don't use the PW_CLIENTONLY flag. Provided by the default window procedure, DefWindowProc(). It is pretty straight-forward, it creates a memory DC and sends WM_PAINT. So what you get in the bitmap is the same you get on the screen. Everybody happy.
But that only works for windows that actually use WM_PAINT to render their content. The chips are down when it doesn't, most any game actually renders with DirectX and does so at a high rate, not relying on WM_PAINT messages. A program that uses a layered window with alpha transparency doesn't either, you can typically recognize them from a fancy blended border.
What such a program should do is write their own message handler for WM_PRINT/CLIENT and render their surface into the device context. Necessary because the default implementation doesn't know beans about DirectX surfaces.
Games just don't do this, that's extra code they have to write that just about nobody ever actually uses. You'll inevitably end up with an empty bitmap. Nothing you can do about it of course.
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
Great insight. Thanks. It appears that capturing Unity windows doesn't work too. So, if DirectX windows don't process WM_PRINT, how to detect them? Is possible to "probe" that window actually processes certain message? How DirectX pixels end up in window frame on desktop - are they already selected into some DC? If yes, maybe it is possible to dump them from there?
– anatoly techtonik
Jun 7 '15 at 8:59
1
I'm 98% sure that you cannot reliably detect such a window. There are just no window properties that scream "My content is rendered by DirectX". Only the empty bitmap is a cue. You'll need to build in an option that the user can change, falling back to BitBlt() like the PrintScreen key does. Albeit that it is fairly doomed that the user will always turn on that option because it always works.
– Hans Passant
Jun 7 '15 at 9:13
Nice. That comment fits into the answer to original question.
– anatoly techtonik
Jun 7 '15 at 9:15
BitBltis not guaranteed to work. It can be disabled explicitly through SetWindowDisplayAffinity.
– IInspectable
Jun 7 '15 at 9:23
Not to argue or anything, but how doesWM_PAINTto a memory DC work? Since standard handling forWM_PAINTis to callBeginPaintand use the DC returned by that.
– Jonathan Potter
Jun 7 '15 at 10:46
|
show 1 more comment
up vote
1
down vote
The documentation for PrintWindow provides information on its implementation:
The application that owns the window referenced by hWnd processes the PrintWindow call and renders the image in the device context that is referenced by hdcBlt. The application receives a WM_PRINT message or, if the PW_PRINTCLIENT flag is specified, a WM_PRINTCLIENT message. For more information, see WM_PRINT and WM_PRINTCLIENT.
Whether or not PrintWindow returns a window's content is subject to the window procedure handling the WM_PRINT or WM_PRINTCLIENT message[1] appropriately. If a window doesn't handle either of those messages, it will not render anything into the provided device context.
[1]Standard window implementations provide a message handler for
WM_PRINT/WM_PRINTCLIENT through DefWindowProc. Custom window class implementations need to provide their own.answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
Not that easy, WM_PRINT has a default implementation in DefWindowProc(). The odds it will work in a program that uses DirectX, like a game, that's zero.
– Hans Passant
Jun 6 '15 at 23:58
@Hans: Updated the answer to make it more obvious, that handling a message does not necessarily equate to writing your own implementation.
– IInspectable
Jun 7 '15 at 8:25
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f30682228%2ftroubleshoot-why-printwindow-is-blank%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Every window has a default implementation for WM_PRINT, you will use it if you call PrintWindow() and don't use the PW_CLIENTONLY flag. Provided by the default window procedure, DefWindowProc(). It is pretty straight-forward, it creates a memory DC and sends WM_PAINT. So what you get in the bitmap is the same you get on the screen. Everybody happy.
But that only works for windows that actually use WM_PAINT to render their content. The chips are down when it doesn't, most any game actually renders with DirectX and does so at a high rate, not relying on WM_PAINT messages. A program that uses a layered window with alpha transparency doesn't either, you can typically recognize them from a fancy blended border.
What such a program should do is write their own message handler for WM_PRINT/CLIENT and render their surface into the device context. Necessary because the default implementation doesn't know beans about DirectX surfaces.
Games just don't do this, that's extra code they have to write that just about nobody ever actually uses. You'll inevitably end up with an empty bitmap. Nothing you can do about it of course.
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
Great insight. Thanks. It appears that capturing Unity windows doesn't work too. So, if DirectX windows don't process WM_PRINT, how to detect them? Is possible to "probe" that window actually processes certain message? How DirectX pixels end up in window frame on desktop - are they already selected into some DC? If yes, maybe it is possible to dump them from there?
– anatoly techtonik
Jun 7 '15 at 8:59
1
I'm 98% sure that you cannot reliably detect such a window. There are just no window properties that scream "My content is rendered by DirectX". Only the empty bitmap is a cue. You'll need to build in an option that the user can change, falling back to BitBlt() like the PrintScreen key does. Albeit that it is fairly doomed that the user will always turn on that option because it always works.
– Hans Passant
Jun 7 '15 at 9:13
Nice. That comment fits into the answer to original question.
– anatoly techtonik
Jun 7 '15 at 9:15
BitBltis not guaranteed to work. It can be disabled explicitly through SetWindowDisplayAffinity.
– IInspectable
Jun 7 '15 at 9:23
Not to argue or anything, but how doesWM_PAINTto a memory DC work? Since standard handling forWM_PAINTis to callBeginPaintand use the DC returned by that.
– Jonathan Potter
Jun 7 '15 at 10:46
|
show 1 more comment
up vote
2
down vote
accepted
Every window has a default implementation for WM_PRINT, you will use it if you call PrintWindow() and don't use the PW_CLIENTONLY flag. Provided by the default window procedure, DefWindowProc(). It is pretty straight-forward, it creates a memory DC and sends WM_PAINT. So what you get in the bitmap is the same you get on the screen. Everybody happy.
But that only works for windows that actually use WM_PAINT to render their content. The chips are down when it doesn't, most any game actually renders with DirectX and does so at a high rate, not relying on WM_PAINT messages. A program that uses a layered window with alpha transparency doesn't either, you can typically recognize them from a fancy blended border.
What such a program should do is write their own message handler for WM_PRINT/CLIENT and render their surface into the device context. Necessary because the default implementation doesn't know beans about DirectX surfaces.
Games just don't do this, that's extra code they have to write that just about nobody ever actually uses. You'll inevitably end up with an empty bitmap. Nothing you can do about it of course.
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
Great insight. Thanks. It appears that capturing Unity windows doesn't work too. So, if DirectX windows don't process WM_PRINT, how to detect them? Is possible to "probe" that window actually processes certain message? How DirectX pixels end up in window frame on desktop - are they already selected into some DC? If yes, maybe it is possible to dump them from there?
– anatoly techtonik
Jun 7 '15 at 8:59
1
I'm 98% sure that you cannot reliably detect such a window. There are just no window properties that scream "My content is rendered by DirectX". Only the empty bitmap is a cue. You'll need to build in an option that the user can change, falling back to BitBlt() like the PrintScreen key does. Albeit that it is fairly doomed that the user will always turn on that option because it always works.
– Hans Passant
Jun 7 '15 at 9:13
Nice. That comment fits into the answer to original question.
– anatoly techtonik
Jun 7 '15 at 9:15
BitBltis not guaranteed to work. It can be disabled explicitly through SetWindowDisplayAffinity.
– IInspectable
Jun 7 '15 at 9:23
Not to argue or anything, but how doesWM_PAINTto a memory DC work? Since standard handling forWM_PAINTis to callBeginPaintand use the DC returned by that.
– Jonathan Potter
Jun 7 '15 at 10:46
|
show 1 more comment
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Every window has a default implementation for WM_PRINT, you will use it if you call PrintWindow() and don't use the PW_CLIENTONLY flag. Provided by the default window procedure, DefWindowProc(). It is pretty straight-forward, it creates a memory DC and sends WM_PAINT. So what you get in the bitmap is the same you get on the screen. Everybody happy.
But that only works for windows that actually use WM_PAINT to render their content. The chips are down when it doesn't, most any game actually renders with DirectX and does so at a high rate, not relying on WM_PAINT messages. A program that uses a layered window with alpha transparency doesn't either, you can typically recognize them from a fancy blended border.
What such a program should do is write their own message handler for WM_PRINT/CLIENT and render their surface into the device context. Necessary because the default implementation doesn't know beans about DirectX surfaces.
Games just don't do this, that's extra code they have to write that just about nobody ever actually uses. You'll inevitably end up with an empty bitmap. Nothing you can do about it of course.
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
Every window has a default implementation for WM_PRINT, you will use it if you call PrintWindow() and don't use the PW_CLIENTONLY flag. Provided by the default window procedure, DefWindowProc(). It is pretty straight-forward, it creates a memory DC and sends WM_PAINT. So what you get in the bitmap is the same you get on the screen. Everybody happy.
But that only works for windows that actually use WM_PAINT to render their content. The chips are down when it doesn't, most any game actually renders with DirectX and does so at a high rate, not relying on WM_PAINT messages. A program that uses a layered window with alpha transparency doesn't either, you can typically recognize them from a fancy blended border.
What such a program should do is write their own message handler for WM_PRINT/CLIENT and render their surface into the device context. Necessary because the default implementation doesn't know beans about DirectX surfaces.
Games just don't do this, that's extra code they have to write that just about nobody ever actually uses. You'll inevitably end up with an empty bitmap. Nothing you can do about it of course.
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
answered Jun 7 '15 at 8:48
Hans Passant
782k10612812048
782k10612812048
Great insight. Thanks. It appears that capturing Unity windows doesn't work too. So, if DirectX windows don't process WM_PRINT, how to detect them? Is possible to "probe" that window actually processes certain message? How DirectX pixels end up in window frame on desktop - are they already selected into some DC? If yes, maybe it is possible to dump them from there?
– anatoly techtonik
Jun 7 '15 at 8:59
1
I'm 98% sure that you cannot reliably detect such a window. There are just no window properties that scream "My content is rendered by DirectX". Only the empty bitmap is a cue. You'll need to build in an option that the user can change, falling back to BitBlt() like the PrintScreen key does. Albeit that it is fairly doomed that the user will always turn on that option because it always works.
– Hans Passant
Jun 7 '15 at 9:13
Nice. That comment fits into the answer to original question.
– anatoly techtonik
Jun 7 '15 at 9:15
BitBltis not guaranteed to work. It can be disabled explicitly through SetWindowDisplayAffinity.
– IInspectable
Jun 7 '15 at 9:23
Not to argue or anything, but how doesWM_PAINTto a memory DC work? Since standard handling forWM_PAINTis to callBeginPaintand use the DC returned by that.
– Jonathan Potter
Jun 7 '15 at 10:46
|
show 1 more comment
Great insight. Thanks. It appears that capturing Unity windows doesn't work too. So, if DirectX windows don't process WM_PRINT, how to detect them? Is possible to "probe" that window actually processes certain message? How DirectX pixels end up in window frame on desktop - are they already selected into some DC? If yes, maybe it is possible to dump them from there?
– anatoly techtonik
Jun 7 '15 at 8:59
1
I'm 98% sure that you cannot reliably detect such a window. There are just no window properties that scream "My content is rendered by DirectX". Only the empty bitmap is a cue. You'll need to build in an option that the user can change, falling back to BitBlt() like the PrintScreen key does. Albeit that it is fairly doomed that the user will always turn on that option because it always works.
– Hans Passant
Jun 7 '15 at 9:13
Nice. That comment fits into the answer to original question.
– anatoly techtonik
Jun 7 '15 at 9:15
BitBltis not guaranteed to work. It can be disabled explicitly through SetWindowDisplayAffinity.
– IInspectable
Jun 7 '15 at 9:23
Not to argue or anything, but how doesWM_PAINTto a memory DC work? Since standard handling forWM_PAINTis to callBeginPaintand use the DC returned by that.
– Jonathan Potter
Jun 7 '15 at 10:46
Great insight. Thanks. It appears that capturing Unity windows doesn't work too. So, if DirectX windows don't process WM_PRINT, how to detect them? Is possible to "probe" that window actually processes certain message? How DirectX pixels end up in window frame on desktop - are they already selected into some DC? If yes, maybe it is possible to dump them from there?
– anatoly techtonik
Jun 7 '15 at 8:59
Great insight. Thanks. It appears that capturing Unity windows doesn't work too. So, if DirectX windows don't process WM_PRINT, how to detect them? Is possible to "probe" that window actually processes certain message? How DirectX pixels end up in window frame on desktop - are they already selected into some DC? If yes, maybe it is possible to dump them from there?
– anatoly techtonik
Jun 7 '15 at 8:59
1
1
I'm 98% sure that you cannot reliably detect such a window. There are just no window properties that scream "My content is rendered by DirectX". Only the empty bitmap is a cue. You'll need to build in an option that the user can change, falling back to BitBlt() like the PrintScreen key does. Albeit that it is fairly doomed that the user will always turn on that option because it always works.
– Hans Passant
Jun 7 '15 at 9:13
I'm 98% sure that you cannot reliably detect such a window. There are just no window properties that scream "My content is rendered by DirectX". Only the empty bitmap is a cue. You'll need to build in an option that the user can change, falling back to BitBlt() like the PrintScreen key does. Albeit that it is fairly doomed that the user will always turn on that option because it always works.
– Hans Passant
Jun 7 '15 at 9:13
Nice. That comment fits into the answer to original question.
– anatoly techtonik
Jun 7 '15 at 9:15
Nice. That comment fits into the answer to original question.
– anatoly techtonik
Jun 7 '15 at 9:15
BitBlt is not guaranteed to work. It can be disabled explicitly through SetWindowDisplayAffinity.– IInspectable
Jun 7 '15 at 9:23
BitBlt is not guaranteed to work. It can be disabled explicitly through SetWindowDisplayAffinity.– IInspectable
Jun 7 '15 at 9:23
Not to argue or anything, but how does
WM_PAINT to a memory DC work? Since standard handling for WM_PAINT is to call BeginPaint and use the DC returned by that.– Jonathan Potter
Jun 7 '15 at 10:46
Not to argue or anything, but how does
WM_PAINT to a memory DC work? Since standard handling for WM_PAINT is to call BeginPaint and use the DC returned by that.– Jonathan Potter
Jun 7 '15 at 10:46
|
show 1 more comment
up vote
1
down vote
The documentation for PrintWindow provides information on its implementation:
The application that owns the window referenced by hWnd processes the PrintWindow call and renders the image in the device context that is referenced by hdcBlt. The application receives a WM_PRINT message or, if the PW_PRINTCLIENT flag is specified, a WM_PRINTCLIENT message. For more information, see WM_PRINT and WM_PRINTCLIENT.
Whether or not PrintWindow returns a window's content is subject to the window procedure handling the WM_PRINT or WM_PRINTCLIENT message[1] appropriately. If a window doesn't handle either of those messages, it will not render anything into the provided device context.
[1]Standard window implementations provide a message handler for
WM_PRINT/WM_PRINTCLIENT through DefWindowProc. Custom window class implementations need to provide their own.answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
Not that easy, WM_PRINT has a default implementation in DefWindowProc(). The odds it will work in a program that uses DirectX, like a game, that's zero.
– Hans Passant
Jun 6 '15 at 23:58
@Hans: Updated the answer to make it more obvious, that handling a message does not necessarily equate to writing your own implementation.
– IInspectable
Jun 7 '15 at 8:25
add a comment |
up vote
1
down vote
The documentation for PrintWindow provides information on its implementation:
The application that owns the window referenced by hWnd processes the PrintWindow call and renders the image in the device context that is referenced by hdcBlt. The application receives a WM_PRINT message or, if the PW_PRINTCLIENT flag is specified, a WM_PRINTCLIENT message. For more information, see WM_PRINT and WM_PRINTCLIENT.
Whether or not PrintWindow returns a window's content is subject to the window procedure handling the WM_PRINT or WM_PRINTCLIENT message[1] appropriately. If a window doesn't handle either of those messages, it will not render anything into the provided device context.
[1]Standard window implementations provide a message handler for
WM_PRINT/WM_PRINTCLIENT through DefWindowProc. Custom window class implementations need to provide their own.answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
Not that easy, WM_PRINT has a default implementation in DefWindowProc(). The odds it will work in a program that uses DirectX, like a game, that's zero.
– Hans Passant
Jun 6 '15 at 23:58
@Hans: Updated the answer to make it more obvious, that handling a message does not necessarily equate to writing your own implementation.
– IInspectable
Jun 7 '15 at 8:25
add a comment |
up vote
1
down vote
up vote
1
down vote
The documentation for PrintWindow provides information on its implementation:
The application that owns the window referenced by hWnd processes the PrintWindow call and renders the image in the device context that is referenced by hdcBlt. The application receives a WM_PRINT message or, if the PW_PRINTCLIENT flag is specified, a WM_PRINTCLIENT message. For more information, see WM_PRINT and WM_PRINTCLIENT.
Whether or not PrintWindow returns a window's content is subject to the window procedure handling the WM_PRINT or WM_PRINTCLIENT message[1] appropriately. If a window doesn't handle either of those messages, it will not render anything into the provided device context.
[1]Standard window implementations provide a message handler for
WM_PRINT/WM_PRINTCLIENT through DefWindowProc. Custom window class implementations need to provide their own.answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
The documentation for PrintWindow provides information on its implementation:
The application that owns the window referenced by hWnd processes the PrintWindow call and renders the image in the device context that is referenced by hdcBlt. The application receives a WM_PRINT message or, if the PW_PRINTCLIENT flag is specified, a WM_PRINTCLIENT message. For more information, see WM_PRINT and WM_PRINTCLIENT.
Whether or not PrintWindow returns a window's content is subject to the window procedure handling the WM_PRINT or WM_PRINTCLIENT message[1] appropriately. If a window doesn't handle either of those messages, it will not render anything into the provided device context.
[1]Standard window implementations provide a message handler for
WM_PRINT/WM_PRINTCLIENT through DefWindowProc. Custom window class implementations need to provide their own.answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
edited Jun 7 '15 at 8:36
answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
answered Jun 6 '15 at 23:33
IInspectable
25.7k54393
25.7k54393
Not that easy, WM_PRINT has a default implementation in DefWindowProc(). The odds it will work in a program that uses DirectX, like a game, that's zero.
– Hans Passant
Jun 6 '15 at 23:58
@Hans: Updated the answer to make it more obvious, that handling a message does not necessarily equate to writing your own implementation.
– IInspectable
Jun 7 '15 at 8:25
add a comment |
Not that easy, WM_PRINT has a default implementation in DefWindowProc(). The odds it will work in a program that uses DirectX, like a game, that's zero.
– Hans Passant
Jun 6 '15 at 23:58
@Hans: Updated the answer to make it more obvious, that handling a message does not necessarily equate to writing your own implementation.
– IInspectable
Jun 7 '15 at 8:25
Not that easy, WM_PRINT has a default implementation in DefWindowProc(). The odds it will work in a program that uses DirectX, like a game, that's zero.
– Hans Passant
Jun 6 '15 at 23:58
Not that easy, WM_PRINT has a default implementation in DefWindowProc(). The odds it will work in a program that uses DirectX, like a game, that's zero.
– Hans Passant
Jun 6 '15 at 23:58
@Hans: Updated the answer to make it more obvious, that handling a message does not necessarily equate to writing your own implementation.
– IInspectable
Jun 7 '15 at 8:25
@Hans: Updated the answer to make it more obvious, that handling a message does not necessarily equate to writing your own implementation.
– IInspectable
Jun 7 '15 at 8:25
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f30682228%2ftroubleshoot-why-printwindow-is-blank%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
stackoverflow.com/questions/25500137/…
– CodeCaster
Jun 6 '15 at 12:09
@CodeCaster it is not about full screen, but thanks for the pointer.
– anatoly techtonik
Jun 6 '15 at 12:18
@CodeCaster your linked question is about how to get screenshot of desktop. desktop appeared blank, because its content was rendered in a child window. I tried to get children of my app window, but EnumChildWindows failed for it.
– anatoly techtonik
Jun 6 '15 at 12:53
The application is Adobe Air app with ApolloRuntimeContentWindow class.
– anatoly techtonik
Jun 6 '15 at 13:03
Windows have to support
PrintWindowand not all of them do.– Jonathan Potter
Jun 6 '15 at 21:03