I'm using System.Drawing.Graphics.CopyFromScreen to grab a partial screenshot of the desktop. I've noticed some curious behaviour. On some machines, when the application (WPF) window has AllowsTransparency="True", calling CopyFromScreen will capture whats 'under' the window. But on other machines, it captures the calling window too.
I've tried it on a number of machines, and operating systems, and haven't found a pattern. On XP and Windows 7 laptops it captures under the transparent window. On one windows 7 desktop we have, it captures the window itself. Aero, or other Windows 7 display features seem make no difference.
Could it be a graphics card issue? Is there any way to get consistent behaviour across all machines, or to predict or detect when this issue will occur?
EDIT Thanks to the link provided by Hans Passant below, and some further testing, I now understand that this issue connected to window transparency only. On some machines, CopyFromScreen captures all windows, on other machines it only captures non-transparent windows.
Not so sure about the sometimes-not behavior. Layered windows have been behaving oddish since Aero. What is definite is that Graphics.CopyFromScreen() will not capture layered windows by default unless you use the overload that specifies the CopyPixelOperation. The required option is CaptureBlt, described as:
Windows that are layered on top of your window are included in the resulting image. By default, the image contains only your window.
Which is not accurate, "your window" won't be captured if it is a layered window. What's worse is that the method has a bug. You don't only need CaptureBlt, you also need SourceCopy. And the argument validation code doesn't permit that combination, you'll get an InvalidEnumArgumentException when you try to use it.
Well, GDI+ is a bag 'o bugs. You'll find the ugly pinvoke code you'll need to work around this in this answer.
Related
We are building a Windows application in .NET and one of its requirements is touch screen monitor. Other than that, it's a normal windows form based application. But except for making UI items little bigger for touch, I can't find anything I as a developer need to do for the requirement since touch screen is basically mouse operations. Am I missing something?
No, you are not missing anything. Do get the actual hardware hooked up so you can test it, "little bigger" is invariably underestimating the problem of fat fingers. Everything should work from a single click, right-clicks are horribly impractical, double-clicks are best avoided.
The only other thing you'll want to do is go into the Control Panel + Display applet and change the size of standard Windows UI elements. Pick a large window caption font if you want to allow the user to drag or close windows. Make the scrollbars at least twice as wide. And the menu and message box font. Go in the Mouse applet to increase double-click range and time if you want to support that.
If you do not need touch-specific event handling I think it's all you have to do. But touch means more than that and you may want to support it in a better way: http://archive.msdn.microsoft.com/WindowsTouch/Release/ProjectReleases.aspx?ReleaseId=2127
I am currently working on WPF touch-screen application. I am developing it on Windows XP machine. I have tested it on this machine and it works perfectly fine. But when I deploy it to Windows Embedded machine I start to get strange behaviour: all pop up messages, drop down list, context menus appear behind the main window.
I am also setting the focus on my main window, when application loads, to enable context menu on the main screen.
Also my main window's AllowTransparency is set to true, (I have seen people had similar issues when having set to AllowTransparency). And also this didn't happen in the previous release.
Edit: The issues has gone after several compilations, I was unable to reproduce it, but I am still trying.
I also think it has to be something related to graphic driver, as it happens on one windows XP machine, but not on another (hardware is different, one run XP embedded 2nd XP professional).
Any idea why this is happening?
Have you tried forcing the ZIndex of the elements to that they are higher than the main window?
This MSDN blog post describes it's use - but the important part might be:
The first set of Rectangle objects uses the default z-ordering rendering of objects, which is based on the position of the child object in the Canvas collection
So if the order the objects are created has changed (for whatever reason) you might see this behaviour.
Explicitly setting the ZIndex will confirm or deny this.
I'm having problems with the rendering of a WPF app over a remote desktop connection.
The applications chrome is rendering, but none of the content is coming through, as if the window is not drawing. Instead the previous content of the screen is showing in it's place.
This has been a problem with the application running on both Vista & Win 7, with remote control being taken from XP and Win7.
The problem is not application specific, if I create a new WPF app, with just a textblock on the window, it will also not run. (Neather will the windows preview in VS2008 display.)
Is there some trick to getting WPF running under RDP?
I read on Kevin Dente's blog (from a twitter post) that he was having trouble with WPF apps in virtual machines. While not the same as Remote Desktop, it's possible the problem could be the same. Kevin was able to fix his problem by disabling hardware accelleration by creating a DWORD registry value at
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
and then setting it to 1.
His original blog post is here: http://weblogs.asp.net/kdente/archive/2009/10/19/visual-studio-2010-beta-2-editor-performance-fix-running-on-a-virtual-machine.aspx
That may not be your exact solution, but maybe it points you in the right direction.
WPF should render over RDP; it's smart enough to know when it can render in hardware, and when it can't it reverts to its own GDI+ based software rendering. I would make sure you're running .NET Framework 3.5 SP1 on the remote machine, since there were changes to remoting that might pose issues. (See link below.)
I've been developing a WPF app for the past 6 months and it works just fine over RDP. (From Vista and Win7 to XP, Vista and Server 2003.) One important caveat, however, is that it renders using the Classic theme. So if you're using controls that don't have a classic theme, they won't render. If you're just dropping a TextBox on a Window, then obviously that's not your problem.
Check out this question for some links that may be helpful: Are there problems with rendering WPF over Remote Desktop under Windows XP?
I just had this problem with the ribbonwindow not displaying correctly when testing for the first time via RDP - the transparent background was white, the close minimize/maximize buttons were missing, the rounded corners on the bottom of the window were square, and the top row of ribbon buttons were almost impossible to select.
Turns out there was a simple fix for me. Right-click the RDP connection icon (I have it saved on my desktop), select "Edit", then the "experience" tab, and change "detect connection quality automatically" to "LAN (10 Mbps or higher)".
This fixed it for me.
Ade
Did you also try Win7 latest RDP - Win7 connection? The thing is WPF doesn't use GDI to draw elements.
VNC clients (like UltraVNC) probably will do the trick for you as they using much simplier algorithms more like of sending bitmaps.
I have the same problem than the asker. The standard, out-of-the-box Checkbox is not rendering correctly. I can only see if it is checked when hoovering the checkbox. Otherwhise, no difference between checked and unchecked. Important note : It occurs when setting the foreground to white (see here : https://social.msdn.microsoft.com/Forums/vstudio/en-US/1c03db49-7e53-4cbb-9dd1-b328017c4453/wpf-checkbox-and-radiobutton-check-mark-not-showing-under-xp-windows-classic-theme-and-remote?forum=wpf)
Our application used to have this problem with a custom progress bar.
We fixed this by setting the background color of the Border control to White. This leads me to think there is an issue with transparent backgrounds
There is no special trick needed to get WPF content to show across remote desktop. Our WPF-based app renders just fine over RDP (tried from numerous machines) with no problems. We're even using animations, gradients, WriteableBitmap, etc. w/ no problems.
I am relatively new in the WPF world and one thing I immediately noticed is how laggy the window content is drawn when you resize a window. For example if you have scrollbars at the window edges those scrollbars will be partly hidden while shrinking and have space between them and the window border when enlarging.
This even happens with an empty WPF project created in Visual Studio. What's even worse is that it also happens with the background and you can see stuff behind the window (other windows, desktop wallpaper, etc.) leak through when enlarging.
At first I thought that it's an ugly limitation of WPF seeing that native or WinForms applications resize just fine (if written properly). But when I look at Expression Blend the window background stays opaque (though the window content still lags behind). What do they do to prevent described problem and are there any ways to improve resizing to more approximate native/WinForm GUIs?
The reason of lags is nicely explained here
Are you running Vista without SP1 ? From what I have read, this was a common issue that is supposed have been fixed..
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/3960d6a6-e873-455c-9ddc-1e2dd32e090b/
I'm not seeing this behavior, myself. I develop on vista x64 sp1 and/or a virtual pc running xp x32 sp3. Wpf uses directx, could it be your video card/machine? Try running your app on a diff machine and see if you have the same results.
I have the same issue with the interface lagging while resizing. I suspect that the reason for the lag is it is resizing the underlying frame buffers in direct X which is never particularly fast. I am not sure what you can do about it though.
I've been looking for information on this issue as well. I just thought it was a windows "feature" that some intrepid microsoft programmer thought would be cool. I was hoping to be able to turn it off so that window resizes would actually follow my mouse, instead of lagging and then overshooting. Grr.
When I try to use Morae Manager 3.0 to run a Screen Text search on a recording of our prototype (coded in WPF, .NET version 3.5 SP1), the only things that come up are the window titles. We are using Windows XP.
Even when I search for something that is editable, like text typed into a text box, it does not come up.
Screen text for things outside the prototype (e.g. desktop icons) still comes up perfectly.
I contacted TechSmith support on two separate occassions and both times the reply I got was it must be an issue with our technology, since the screen text search does work for other things, and that the support people are not developers and thus do not know what might be causing this.
Does anyone know:
what precisely might be causing this -- e.g. does WPF's rendering engine bypass some sort of Windows layer where Morae looks for text (please forgive me for any errors in terminology)
if there is anything I can tweak in the prototype to fix it
how I can get through to someone at TechSmith who knows the answers to 1. and 2.
P.S. Morae is a wonderful product and we've usually had great support from TechSmith. We are only having problems with this one little thing, and one can hardly blame Morae for not being compatible with something as new as WPF.
I have no idea what Morae is or how it works, but one big difference between WPF and for example WinForms is the following, copied from here:
When you create a WPF Window, WPF
creates a top-level HWND, and uses an
HwndSource to put the Window and its
WPF content inside the HWND. The rest
of your WPF content in the application
shares that singular HWND.
If Morae depends on HWNDs to find texts on the screen, this could explain why it can not find the text box. In contrast, i believe in WinForms every control (button, textbox) has its own HWND.