I have a very strange issue in my WPF project. The main window contains several wpf controls and winforms RichTextbox(don't ask me why) within WindowsFormsHost element.
Richtextbox contains text. In some cases Richtextbox is not properly rendered when loading window (the right part is white like somebody uses erase tool and clears a rectangle).
This situation is not so common (~20 users / 30 000) and it probably depends on hw. It occurs on XP machines. I have tried to force sw rendering, but it didn't help.
Application is built in .net 3.5 SP1.
Any idea?
The problem was caused by user's unusuall dpi settings in Window. Strange, but with normal values, it works
Related
I have a problem that appears to be new to Windows 10.
I want to create a form that is visible to the user, but with no task bar icon and that does not appear in Alt+Tab.
This is perfectly doable if one is happy to sacrifice the normal styling of a window by following the accepted solutions here for either WPF or Windows Forms.
The general advice for both WPF and Windows Forms is:
Set ShowInTaskbar to false
Enable the ToolWindow styling (either through setting the border style in WinForms or the WindowStyle in WPF)
However, this has a new, practical problem in Windows 10 when using Virtual Desktops: the moment you do the above, the WPF or WinForms window will appear in every virtual desktop. See my example application with a red background:
This affects both the Task View switching screen and the actual desktop itself. No matter where you go, the form is there!
Is there any way to show a form - or even just a bitmap - on Windows without anything appearing in the taskbar, without anything appearing in Alt+Tab and without duplicating the window on every virtual desktop?
I have spent two days researching every possible option, trying every example online, reading MSDN documentation on window styles etc. but all resort to the same method, either through P/Invoke calls or directly, but either way the result is the same.
I recently introduced a WPF control to my VB.net WinForms application. The control looks good and works great. However, depending on which environment I run the application, I will get different behavior. The two machines that differ are both running Windows 8.1 with the default theme.
I have read a few questions about adding proper theme settings and I don't believe that is the issue.
In the environment that is incorrect I have observed the following behavior:
Upon loading the form containing the WPF control, the calling form will resize and move around the screen
Controls contained within the form that also contains the WPF control will often "ghost" upon resizing the application
Both the calling form and the form containing the WPF control shrank upon loading the containing form. By shrank I mean window size, control size of all controls, font size, etc...
I'm wondering if the application was built against one version of the library and the DLL versions differ on the deployment environments. But I'm not sure how to look for this.
Has anyone encountered this before?
I found the problem.
This was the result of DPI scaling. The application was acting out anytime the DPI settings were set to anything other than 100%. WPF controls scale differently from Winform controls causing the strange behavior. The following stackoverflow Q/A explains how to remove the DPI dependency
Disable DPI awareness for WPF application
I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.
Is it possible to have a project containing both Winforms and WPF?
Say a WinForm project that is transformed step by step(form by form) in a WPF one, will be possible to have a Winform opening on a button, and a WPF one opening on a other button?
Yes. You have to pick one technology to display each physical window and control in your app, but there's no reason why you can't mix and match.
For example:
A WinForms window can show a WPF window.
A WPF window can show a WinForms window.
A WinForms window can contain WPF content (see the ElementHost control).
A WPF window can contain WinForms controls (see the WindowsFormsHost control).
This works great.
One can have WPF windows in Windows Forms and Windows Forms windows in WPF
http://msdn.microsoft.com/en-us/library/ms745781.aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.windowsformshost.aspx
Adding Winforms to WPF projects can be done smoothly (directly from the "Add new item" menu), but there is not straight option to add a WPF window to a Winforms project. Still, I handled to do it following these steps:
Add a WPF User Control (this option is available on the "Add new
item" menu) and then convert it into a WPF Window. Modify the XAML
changing the UserControl parent tag to Window, and remove the
inheritance from UserControl (all of this is explained in this link).
Add a reference to System.Xaml.dll. See this link.
Add a reference to System.Windows.dll (I found it on my computer on this path: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5. Be aware it might be different in yours). See this link.
What you might be looking for is the ElementHost control. What it lets you do is take WPF content and host it in a Windows Forms window. More details are here:
http://msdn.microsoft.com/en-us/library/ms745781.aspx
There is also a control that lets you do the reverse: host Windows Forms content from within WPF:
http://nayyeri.net/host-windows-forms-controls-in-wpf
Between the two, you can move the 'dividing line' between WPF and Windows Forms with some degree of flexibility.
There is at one caveat you'll need to keep in mind. Windows Forms works internally in terms of HWND's... a window managed by the legacy Windows window manager (which handles the z-order). WPF doesn't do this... A WPF tree is typically rendered into a single HWND', and it's WPF that manages things like z-order. What this means to you is that z-order doesn't always work the way you expect it to, and there are things you can't do with hosted Windows Forms controls that you can do with traditional WPF elements. (There is actually a way to solve this, but it involves periodically rendering the HWND into a memory bitmap, rendering that bitmap into a WPF surface, and then redirecting events directed to the WPF surface to the underlying HWND. This is powerful, but tricky and difficult to get right.)
I see no objection to do that.(I have in WinForms Application WPF windows)
Many of the examples used MessageBox.Show which is part of the Windows.Forms.
Of course you must rewrite all windows, not only controls.
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.