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.
Related
I've been encountering this issue ever since I bought this laptop with 4k display in 2015. With a lot of effort I managed to work around the issue but I'm growing tired of it.
VS2017 is supposedly DPI aware hence I do not expect any issues when creating a simple MDI Parent Form and running the app. But to my frustration the icons in the toolStrip (just the standard one in the MDI parent form) are scaled horribly.
When I create a form with a button on it which looks just fine in Visual Studio 2017 designer and I run the app and load the form, the button text isn't completely shown.
My display settings are as follows:
Resolution: 3840x2160
Scaled 250% (in display settings) because at 100% everything is unreadable
I've tried to find solutions, but the only workable thing I could find was setting my visual studio designer to dpi-unaware via registry (link here)
Help anyone?
Update When I add a new MDI form with the setting of DPI-awareness OFF, everything looks OK except Visual Studio itself (blurry).
I have similar problem when working with Windows Forms (Windows Forms Designer) on Visual Studio 2017, but I think it would be the same on Visual Studio 2019.
From Microsoft documentation here, there is a tip to disable the scaling/DPI aware feature.
If you prefer to manage settings from the command line, devenv.exe
takes /noscale as a command-line parameter to run in 100% scaling
mode.
So, basically, I just created a shortcut on the Desktop to Visual Studio (devenv.exe) and added the parameter /noscale on the shortcut Target field like so:
"...\path\to\IDE\devenv.exe" /noscale
So, everytime Visual Studio is started through the shortcut, it will always start with 100% scaling mode. If you use high resolution screen (high-dpi) screen, you will notice that the Visual Studio text will appear a little bit blurry because of this.
You should change the settings so there won't be a difference when the program runs on different machines.
Go to the project's properties page, then to Manifest Tool and then Input and Output. Change the DPI awareness to 'none'
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.
I am having trouble with the JIT Debugger. I have a windows forms application which calls into a .NET assembly which has a function called calc(int,int) which has a break point set using the System.Debugger.Break(). This assembly is loaded when I click on a button in the forms application. Now, when the breakpoint is hit the JIT debugger asks me if I want to debug the application. I choose to do so and select a current instance of visual studio which has the project for the forms application I was running loaded. VS successfully breaks at this call. Now when I click on run I expected the forms application to return to a state where I can interact with it again.Instead, what I get is a "ghost" window of the forms application. Is there anyway to get around this problem? I know attaching the forms application to the VS debugger before the breakpoint is one solution. But is there any way to get this behavior when I use the JIT debugger?
Thank You.
I am developing a Windows Forms application using VS2008 on Windows Vista. I tried to run my application on Windows XP the other day, and everything on GUI was messed up. I realized that I developed the application using 120 Dpi setting on Windows Vista and my XP was set to 96 dpi.
My application has several UserControls and all of them shrinks even in the Visual Studio itself if I change my DPI to 96. I am sure a lot of people are using Visual Studio in high DPIs these days. So how can make sure that my GUI does not get messed up both in Visual Studio and runtime?
EDIT: I have read couple articles on this issue and I learned that I should be setting AutoScaleMode to None. However, this still does not prevent my labels to adapt new DPI settings enforced by the operating system. I need a way to prevent my labels to grow/shrink because other GUI elements have fix sizes.
It has been a while since I worked on this issue, but try setting AutoSize = False. In addition, UseCompatibleTextRendering = True might help.
This is a rather old question, but I want to share my solution/opinion. I ran into a similar problem recently. Actually, I want Visual Studio to keep my WinForms as they are, but them to scale at runtime. I found no consistent summary on how to correctly do that. After some reading and experimenting I came to this solution:
Keep the Form’s AutoScaleMode = Font.
Set in your Forms Designer: Font = MS Sans; 11px
In the Forms Ctor, after InitializeComponent, set: Font = SystemFonts.DefaultFont
Enable DPI-Awareness, either through a manifest or by API function SetProcessDPIAwareness
Since AutoScaleMode remains active, all DPI-changing magic works, even per-monitor DPI awareness. What remains, is designing Forms in a way scaling works nicely.
I wrote the details on my Blog: http://www.sgrottel.de/?p=1581&lang=en
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.