I started facing the weird problem recently on my new laptop.
I installed a fresh copy of Windows 8.1 and then Visual Studio Ultimate 2013.
It worked fine for the first few hours, but the next time I opened it, it did not show the UI elements in the XAML Designer view. There's no error, the XAML code is perfectly alright and then on hovering over the supposed-to-be-visible elements, their outline is visible as well as selectable.
Surprisingly this is the case only with all new Windows Store Projects I open or create. The Windows Phone App Designer View works perfectly fine.
I reinstalled Visual Studio a couple of times and at last even formatted the OS and reinstalled it, but the problem still persists.
#JTIM: Sure!!
Posted by Varun Mashru on 5/23/2014 at 3:54 AM on Visual Studio Feedback Forum
Surprisingly and fortunately, I found the solution just two days ago.
It bit of a bummer but that's what it is.
Its nothing to do with the VS setup or the OS.
The first thing to notice here is that it happens with notebooks only.
The REASON??
Because notebooks do not have completely dedicated GPUs. These GPUs
act as secondary processors for the onboard graphics solution which is
directly connected to the display. Hence they fire up only when
needed.
My notebook Dell Inspiron 15 3537 -- Core i5 4200U (Intel HD Graphics
4400 onboard) + AMD Radeon HD 8670M has got a switchable graphics
solution. Hence the software chooses as to which GPU does the
weight-lifting.
The power settings when cranked up to the max indicate that the AMD
GPU must be the one that should take the lead.
And in the case of VS it does not happen properly (Don't know why??).
Maybe the UI components cant decide that which GPU processor to choose
or whatever.
So the simple workaround I found was to bring the graphics settings
down by just a notch. Which is selecting the 'Optimize Performance'
option in the Switchable Graphics instead of 'Maximize Performance'
field in the power plans.
And voila, It works perfectly fine!!!!
Share this with everyone who has freaked out for months on this
issue!! :)
Related
I am developing a WPF application that displays a directX scene.
The code that generates the directX scene is not mine and I have no access to it. (Its not a public code I can references you guys to)
Everything was working fine until I had to format my PC and installed Windows 10. (Before that I had Windows 7)
Now I can't see the DirectX scene and the RenderCapability.Tier on WPF returns 0.
The code works on other computers (Windows 7 and Windows 10) so I'm guessing its something to do with my computer but nothing changed hardware-wise..
I tried reinstalling DirectX and I tried reinstalling the display driver (tried several different drivers) but nothing works I still get RenderCapability.Tier = 0.
The code that displays the DirectX scene is mostly taken from this link:
https://www.codeproject.com/Articles/28526/Introduction-to-D3DImage
I couldn't find any help around the internet that actually solved my problem.
Any help would be appreciated.
Thanks!
Run dxdiag.exe, Display tab, ensure it prints "D3D acceleration: enabled" and "No problems found".
Also the linked sample has a bug, on some systems you must use a query to wait for completion of rendering before passing the texture to WPF. Otherwise WPF may show incomplete renderings, or none at all. If you render with DX9, see this, you need D3DQUERYTYPE_EVENT query, issue D3DISSUE_END after you've done rendering, then sleep until GetData returns S_OK.
I had been developing WinForm apps in a long time. I just recently bought a Surface Pro 3 to serve as my new development PC. Unfortunately I noticed an issue with the GUI editor. The some of the sizes of the controls don't match with what appears in the GUI editor and with what appears in the actual running application. For example, the sizes of my panels don't follow what it looks like in the GUI editor when I run the app. They usually increase in dimension. I am not really sure if it is a VS issue or maybe it has something to do specifically with using Surface Pro 3?
To demonstrate what I mean consider the following screenshots. Notice the difference in the size of the Menu Bar in the GUI Editor and in the actual application.
If you want to prevent your app from changing size, you can make it independent of DPI settings. Your app will be pixel perfect but on high resolution screens may be too small.
All you have to do is to change AutoScaleMode property of the main form and set it as None.
I know this is an old thread but I was experiencing the same issue... I found a workaround which you may find useful...
After trying a few things it became obvious to me that windows 10 was attempting some "intelligent" resizing of forms under Windows 10 on the surface pro (I am using a surface pro 4)... I am not sure if it is a win10, high-res or surface pro issue.... whatever it is it was messing up my control sizing, placement, anchors and resolution.
I found that if I made a note of the intended size of my form in the designer and then manually set this in code at the end of my Form_Load event, it would override this unintended behaviour and I ended up with my originally intended form size and control placement, I also needed to re-center the form in the parent/screen to get the desired result (of course only if that is the intended start-up position for your form)
The code that worked for me (at the end of the Form_Load event) is...
this.height = 800;
this.width = 600;
this.CenterToScreen();
I hope this helps somebody, I was pulling my hair out for a while!
It has been a while since I posted this question and I kinda forgot about it. I thought I should share my recent findings for those who will find themselves in this same predicament.
I learned that the discrepancy between the GUI editor and the actual running app was because of the super high DPI scaling of my Surface Pro 3. Visual Studio was automatically running at 216 DPI (225% display scaling) compared to the usual 96 DPI (100% display scaling) of common computers. My workaround back then was to simply adjust my controls accordingly thru trial and error and to anchor most of them between the GUI editor and the running app. Eventually, it became less of an issue since I moved on to a normal desktop with a normal screen for my regular software development. Moving forward, I recently stumbled upon a Microsoft documentation regarding Automatic Scaling in Windows Forms. It explains the issues with multiple DPI scaling for Windows Forms. It also includes this bit about the DPI scaling issue of Visual Studio:
With the extreme differences in display DPIs, especially in modern 2-in-1 devices, this can still happen with the most current versions of the .NET Framework and Visual Studio. To address this in a team using different DPI displays, make sure Visual Studio always starts in a non-DPI-aware mode, so the Windows Forms designer always bases the layout calculation on 96 DPI.
The solution they suggested is to add or import a registry value that disables Visual Studio's High DPI awareness:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\devenv.exe]
"dpiAwareness"=dword:00000000
I tried it and it definitely works. I hope it helps you too. :)
This issue is getting real tiresome and I've been spending atleast 2 days looking around for an answer. Basically, I want to publish a game, and I've hired a friend of mine to test it out before I officially release it. Whenever he runs it, reports as "nothing happends".
These conditions are met:
He has installed the .NET Framework 4.0 and the XNA Redistributable 4.0 (he most likely also has installed other .NET Frameworks and XNA Frameworks as well, because nothing worked).
The game is compiled onto a Release build.
GamerService referenced is removed.
A possible issue could be that he's using Win8, but as my searching experience goes, XNA DEVELOPMENT is only restricted on Windows 8, right?
So, what's going on? I'm clueless.. I even put a MessageBox.Show(); after the execution of my game in my Program.cs file via try/catch, and no results.
Are there any extreme conditions in my code that I need to meet?
Any site describing 100% of all requirements to run an XNA game and the most proper way to build it?
Any issues when using non-distributable "developer tools" in XNA coding? If so, what includes in these "developer tools", and what do I need to modify? (I noticed that on another thread).
An answer to this issue would more than make my day...
Ah, and also, I tried running it on a virtual machine ( Windows 7 ) but then it spat out a messagebox saying Index outside the bounds of the array on a perfectly valid code execution, and various other random errors such as missing files when they clearly are there.
Thank you greatly!
In summary I think your app wont run on Windows 8, let me explain:
Windows 8
A possible issue could be that he's using Win8, but as my searching experience goes, XNA DEVELOPMENT is only restricted on Windows 8, right?
Officially, desktop games using unmodified Microsoft XNA 4/is not supported on Windows 8 in any form:
Microsoft officials have said the XNA tools/runtime environment used primarily by game developers isn't supported on Windows 8. - Read more...
Redistributables
Any issues when using non-distributable "developer tools" in XNA coding?
That depends on whether they are required at runtime on the target machine. That might sound like an oxymoron but in Windows c/c++, I can have an app that depends on Microsoft DLLs but we are not allowed to deploy the DLLs, one must depend on it being present in the OS; service pack or some other form. Is there something you are missing?
Windows 7
Ah, and also, I tried running it on a virtual machine ( Windows 7 ) but then it spat out a messagebox saying Index outside the bounds of the array on a perfectly valid code execution
This is more interesting and I suspect is one of the more testable aspects of your application (also that it is not Windows 8). I suggest you setup a remote-debug session to your Win7 VM or if that is not possible, use Debug.WriteLine() or equivalent displaying critical state contents.
While running performance tests my application suddenly started giving blue screen shortly after the UI was loaded.
In the code im receiving the following error:
{"Error HRESULT E_FAIL has been returned from a call to a COM component."}
"The GPU device instance has been suspended. Use GetDeviceRemovedReason to determine the appropriate action.\r\n"
After looking around on google i wasn't able to find anything usefull. The main answers given didn't work such as installing driver updates or reinstalling the application. Keep in mind this is an app in development and it was working fine earlier this day. Between two test launches this happened.
EDIT
After testing the application on a tablet it turns out the development pc is the only machine with the UI loading bug. Going to look into it some more and ill let you guys know if i find a solution.
Edit 2
So after testing the app on the tablet and finding that it works fine there we decided to test the app on a 2nd development pc. Needless to say the same thing happened... in other words its a rendering issue that happens on windows 8.1 PC's but not on a tablet.
Facts as of now:
- Code worked yesterday, no longer works now
- Works on tablet but not on PC
- Nothing changed in the code since it worked
- Seems to happen in the rendering stages
- Bug happens when loading more than 23 items in a listview, app restores itself then
- Any more than 23 items and it stays bugged (dark blue screen but still responds to clicks)
I have a wierd problem that i need to work out how to resolve,
I have spent the last couple of weeks working on a project for work on my laptop, but when I open the program on one of the work pcs alot of the controls are the wrong size and over lap etc,
the differences between the machines is this:
Laptop:
Windows 7 Pro;
Display - 1920*1040;
Visiual Studio 2008;
.net framework 3.5
Work Desktop:
windows xp pro;
display: 1024*768;
visual studio 2008;
.net framework 3.5;
to discribe the problem better, i have a panel which i have set to be 300px wide, which has a label inside with the day and the day in the mm-DD-yyyy format, using arial and size 8 font.
On the laptop it all fits perfectly but on the desktop the panel seems smaller and the label only displays half the text.
That is just one of many problems, another is with colour system.control seems to be a completly different colour between systems (althoug I figure that to be a win7 vs xp problem)
What can I do to fix this?
is it a windows version problem? (I have xp on a vmware machine on my laptop so i could code and design in that)
is it a display problem? - this is a big problem for me as i only have 1 laptop and I think this problem could have caused me mark loss on my recent assignment for Uni (I coded on laptop and never opened on a desktop untill today - so had no idea of this problem)
EDIT: I have found a solution of sorts for my particular problem, I discovered that my laptop was working on 125% on the dpi settings for visually impaired (no idea how..) so I have reset it back to 100% or 96Dpi Which has fixed my problems, and after chatting to a couple of other developers I know, they say that they tend to design for 96 dpi while leaving a little bit of white space around text to be safe. but then they don't tend to use c# much and mainly code all in c++ using QT framework.
The video adapter in your workstation has a different dots-per-inch setting. The form automatically rescales itself to accommodate that.
This is going to happen as well when you ship your product and it will run on the client's machine. Changing the form's AutoScaleMode property is not a fix, that will just produce clipped text in the controls. Make sure you form design is resilient to layout changes. Dock, Anchor, TableLayoutPanel, FlowLayoutPanel, the Resize event for tough cases. And make sure the controls inherit their container's Font property (not bold in the Properties window)
Ensure you can resize your panel in Visual Studio with all of the controls inside it being repositioned and resized properly. You can use anchors to achieve this, or perhaps you should use a TableLayoutPanel control instead of a regular Panel.
Change your setting for AutoScaleMode.