An application that I've written (https://github.com/JuliusSweetland/OptiKey) requests UIAccess (to be able to be rendered above everything) and has a modal popup window styled using MahApps.Metro. When run on Windows 8/8.1 everything is fine, but on Windows 10 the popup window does not display (is not rendered anywhere), but is visible in the taskbar. Hovering over the thumbnail displays the preview, but the window can never be made visible.
I have narrowed the problem down to Windows 10 and whether the UIAccess="true" setting in the manifest is true/false (it is fine if set to false).
I initially thought the problem was linked to the .Net 2.0.0.0 runtime not being present on a default install of Windows 10, as the problem went away when I installed Snoop (which I think installed .Net 3.5 and so the 2.0.0.0 runtime), but to prove the fix I uninstalled .Net 3.5, which brought back the issue with the child window, and then re-installed .Net 3.5, which did NOT resolve the issue again.
I have tried the following:
Running application as admin = no fix
Updating all graphics drivers = no fix
Checking the event logs = nothing
Converting my child (popup) window to be non-modal = no fix
Converting my child (popup) window to be a standard Window class, rather than a MetroWindow (MahApps) = no fix
4 & 5 = no fix
Installing .Net 3.5 = no fix
The only thing that works is setting UIAccess="false", but I need it to be true.
N.B. UIAccess is working correctly on Windows 8.1, and I have fulfilled the requirements (adding UIAccess="true" to the manifest, signing the assembly, and running from a protected directory "Program Files")
Any idea what is going on?
Found the issue - as part of launching the child window I was setting the parent window's TopMost property to false (and then setting it back to its original value when the child window closed). Something about setting parentWindow.TopMost=false was causing the invisible child window problem. I removed the relevant lines (in this commit: https://github.com/JuliusSweetland/OptiKey/commit/e9031119a726518f54da94c64faceeee991b3747) and everything works again.
Related
Using the following tutorial, within a VSIX project, I created a WPF window that inherits from Microsoft.VisualStudio.PlatformUI.DialogWindow, and I display this modally using the following code:
var myWindow = new MyWindow(myParameters);
myWindow.ShowDialog();
When I compile this in RELEASE mode and start without debugging [Ctrl+F5], it opens the Experimental version of Visual Studio. Here, I open another Solution and then execute my Modal Window. The window works just fine - I can type in text boxes etc, etc.
However, when I close the modal dialog window [using this.Close()], the problems start. If I navigate to one of the documents in the open solution, I can type, but the keyboard buttons backspace [<-] and [Delete] (and possibly others too) are simply ignored....I can't delete what I've just typed!
Also, when I try to close this experimental version of Visual Studio, I get the following message:
Microsoft Visual Studio has detected that an operation is blocking
user input. This can be caused by an active modal dialog or a task
that needs to block user interaction. Would you like to shut down
anyway?
But, as far as I can tell, my modal window has been closed and may even have been garbage collected by the time I get to close this instance of Visual Studio.
This isn't limited to the Experimental version - when I push this VSIX to our local gallery and install as an Extension, then I get the same behaviour.
I have also tried explicitly setting the owner, but his had no effect on this problem:
var myWindow = new MyWindow(myParameters)
{
Owner = Application.Curent.MainWindow
}
myWindow.ShowDialog();
If I make this a non-modal window, then I get different (but related) problems. Here, if I open the Experimental version of Visual Studio and open the other Solution where I navigate to a C# page. I then open my Extension's WPF window where I can happily type into TextBoxes in that WPF window. However, whenever I click the backspace [<-] or the [delete] keys, this doesn't affect the current WPF textbox but the previously opened C# code window in the current solution. See a previous post on this
What am I missing?
The following suggestion found here seems to work for me:
IVsUIShell uiShell = (IVsUIShell)ServiceProvider.GetService(typeof(SVsUIShell));
uiShell.EnableModeless(0);
var myWindow = new MyWindow(myParameters)
{
Owner = Application.Curent.MainWindow
}
myWindow.ShowDialog();
uiShell.EnableModeless(1);
I am debugging a Windows form application in visual studio 2012. How can i see the snapshot of the UI while debugging?
Print screen is built in to windows. Sometimes labelled "PrtSc" on the keyboard. Use Alt-printscreen to snapshot just the window. There is also a "Snipping tool" program available in some versions of windows.
In Windows Vista and Later, the Desktop theme may affect the appearance of the App UI when the code is frozen at a breakpoint within the debugger. In Windows 7, for example: with Aero theme enabled, the current app UI is usually still visible if other obscuring windows are moved or closed, because Aero retains an image of the UI. So, for example, minimizing Visual Studio will typically let you see the application again.
If Aero is disabled (eg switch to a Basic theme in Win 7), then the app UI will not respond to paint events, and if other windows on top of it are removed or moved, the result is gibberish. If working on 1 monitor, once Visual Studio stops at a breakpoint you will no longer be able to see the UI until the code runs and responds to any pending Paint events.
So, if your question was about the UI freezing when the code is paused, enabling Aero might solve it.
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.
Wondering if anybody else has found some very odd behaviour with the XAML/WPF 4 editor in VS2010, and can explain what is going wrong. This only occurs if the project is using .NET 4.
Whenever I tried to open a XAML document for editing, the window would appear to open for a split second and then vanish, but VS2010 would still list the window as open.
The fault was eventually traced to having the "Reuse current document window, if saved" option under "Documents" in the "Environment" options checked. Once this was unchecked XAML 4 files opened as expected.
As I said, this only appears to occur on projects targeted at .NET Framework 4 - those targeted at 3.5 worked without a problem, and the "Reuse current document window, if saved" appears to work fine on other files.
you can use online XAML editor http://www.silverlightshow.net/news/New-Online-XAML-Interface-Designer-Released-Open-Source.aspx
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.