Application built with VS 2015, C#, Winforms, using the DateTimePicker Windows control, text is garbled after updating machines to the Windows Creators Update.
Has anyone else come across this or is there any suggested work around ?
Enable Visual Styles in the WinForms application, before the Form containing the DateTimePicker is shown.
Application.EnableVisualStyles();
//Form1 contains the DateTimePicker component
Application.Run(new Form1());
The June cumulative update for Windows 10 (KB 4022725) includes an updated COMCTL32.DLL that contains a fix for this issue. The file version should be 5.82.15063.413 after the update is installed.
https://social.msdn.microsoft.com/Forums/en-US/4cf03067-46c4-4962-af8c-f4b1483e88ba/date-time-picker-garbled-after-windows-10-creators-update?forum=windowsgeneraldevelopmentissues
Do you have a High-DPI display? Even if you don't, there's a good chance the updated dpi scaling is at fault here. If so, you might be able to "fix" this simply by setting a value in dpiAware and dpiAwareness values of the manifest file for your project as described here:
High-DPI Scaling Improvements for Desktop Applications in the Windows 10 Creators Update
I haven't had to do this myself yet, so right now I can only point you where to look, and not to what the exact right values should be for your situation.
Even if this isn't your issue, you may want to spend a few minutes checking that your app handles well in High-DPI situation. It's also a decent excuse to get your company to buy you a nice new monitor :)
Enabling XP Visual Styles fixed it for me.
So Windows 10 1703 has introduced some new challenges, among them this weird refusal to display a date in the DateTimePicker control, unless you tick the "Enable XP visual style" box for the application (or do it programmatically). This tweak does fix the date-rendition issue, but now other controls, such as dropdown boxes, dropdown lists text boxes and buttons become flat and dreary. Not good. What we do need is a real fix which makes the "XP visual style" unnecessary, or is Windows Forms programming on the way out and so not interesting to support?
I have also come across this today. My datetimepicker was rendered very randomly, but never acceptible. I have this as a sort-of workaround:
My environment is VS2015, .net 3.5 and winforms
My setup is Surface Pro 3 with the new docker and 2 external monitors res 2560x1440 and scaling 100%.
Added app.manifest to my project as I did not have it before.
Added the dpiAware to app.manifest to be System like this:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/System</dpiAware>
</windowsSettings>
</application>
I also set the AutoScaleMode to None on my form (but got approx the same result with Inherited).
The dpiAware seemed to help (but not 100% stable). This does work when running a compiled application, but does NOT work when debugging from Visual Studio. Then I only get a period (.) that is my date separation sign.
sample of datetimepicker after updating to creators update
after applying workaround when running compiled exe
this can help a bit if unable to update application to .net 4.7
So, we wound up deleting the manifest file and the control now renders correctly.
What's odd is just the fact of including a new manifest file with only an assemblyIdentity tag with version and name causes this windows control to freak out.
I realize that for others, deleting the manifest may not be an option, but, this has fixed our issue.
We are receiving this exact same issue. VB.NET VS 2012 .NET 4.5. THe datetimepicker is messed up. I have also posted this on
https://connect.microsoft.com/VisualStudio/feedback/details/3129203/date-in-datetime-of-mfc-application-is-getting-cropped-in-win10-redstone2-build-15055
I tried most of the suggestions here and in other places including manifest changes, .NET 4.7, etc. However, one additional change that was required in my setup was to increase the CalendarFont size on the control itself.
The default on my system was 7.875. Changing it to 10pt corrected the display issue (changing it to a slightly lower value improved the display but did not correct it).
Disclaimer: This has not been tested in-depth and may break other scenarios. This information is intended to assist in finding a final solution.
Like other have suggested, had this line to your main form and it worked for me:
Application.EnableVisualStyles()
You can also uncomment the lines at the bottom in the app.manifest. It depends of the project.
A fix for this issue is scheduled to be included in the June cumulative update for Windows 10.
This is a bug in the Date Time Picker control implemented in COMCTL32.DLL version 5. There should be a fix for this issue in the near future.
The Date Time Picker control implemented in COMCTL32.DLL version 6 does not appear to be affected by this issue.
Related
Every time we open Visual Studio, the following tab is opened:
Is there a way to disable this behavior?
Perhaps to ask this in a more generic way, in which it would be helpful in other applications, can you disable extensions/dependencies from screwing with your Visual Studio layout?
The web page should pop up only once, when you have installed NServiceBus for the very first time via Nuget. It popping up every time is an anomaly and I agree, is very annoying. That said, we are in the process of removing the Visual Studio Popup starting from Versions 6.1.0 and above. You can find the details of that change here: https://github.com/Particular/NServiceBus/pull/4280
For the current version that is annoying you, i.e. the solution that you're opening that's causing this behavior, can you have a look at the init.ps1 from the nuget package and check to see the registry keys are present?
Feel free to reach out to us directly by opening a support incident here:
https://particular.net/support
Hope this helps. Cheers.
My colleagues and I had the same problem a few years ago.
You can disable the pop up manually by setting a registry string value at:
[HKEY_CURRENT_USER\Software\NServiceBus\{Major.Minor}]
Called MachinePrepared with a value of true.
Had anyone been able to release wpf applications to Windows 7 users and use this font? I have looked all over the place and can't see a solution.
I have downloaded the font family and placed as a resource in my project
FontFamily="/Helpdesk;component/Fonts/seguisym.ttf#Segoe UI Symbol"
This works on my computer however taking off the Segoe UI Symbol in the above gives me a square box.
Any help would be gratefully accepted.
Scott
According to http://www.microsoft.com/typography/fonts/font.aspx?FMID=2027 it's already part of Windows7.
Are you testing against a corporate or an otherwise modifed version of Windows7?
it looks like there is an update for it;
http://support.microsoft.com/kb/2729094
and also there is a similar question to yours in here;
http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/segoe-fonts-appear-as-boxes-after-kb2729094/dbafb137-211e-425e-93f8-d3259d3cee92?auth=1
it say it may related to conflicted with updates and another software.
I had the same problem and finally found a way to use the newer version of "Segoe UI Symbol" even when older version is installed (i.e. on Windows 7). The idea is to create a copy of the font file with a different name. This approach works also in ClickOnce installation and requires no bootstrapping.
It is posted on this link: Embedded Font in WPF not working
I'm stuck on a problem in VS 2010 C# .NET. I've had a project on Windows XP that includes forms, classes and a handful of my own custom components. These components are simple extensions of built-in MS components (e.g. DataGridViewEx as an extension of DataGridView). Everything has worked fine in XP. I'm trying to port this project over to VS 2010 on Windows 7 / x64. I've got the solution to compile OK on Windows 7, however in design mode, when I open a form that contains one of the custom controls, I get an error 'Could not find type XYZ.DataGridViewEx. Please make sure that the assembly that contains this type is referenced.' XYZ is the namespace I use for these controls and it is the same namespace as the forms that are using the controls. All are part of the same VS project.
When I open a form in the same project that does not contain one of these custom controls, that form opens OK in the designer, and I see the custom controls along the left side in the toolbox. However if I then try to drag one of these controls into that form, it pops up an error message box 'Failed to load toolbox item 'DataGridViewEx'. It will be removed from the toolbox.' And then it gets removed from the toolbox.
Everything was always working fine in VS solution in XP. This problem only occurs in the VS solution in Windows 7 / x64.
I don't understand why it complains about not being able to find the component, since the component is part of the same project. That's a valid thing to do, isn't it?
I've search the web/forums and found cases of the 'Could not find type' error, but it seemed to be caused by a different issue, and I haven't yet found a way to get rid of the error.
Any help/tips are much appreciated!
If your project is targeted at 64 bit, you need to build for 32 bit and choose the 32-bit solution while doing your GUI editing. This is because studio is 32-bit so cannot load 64-bit controls.
Ive run into this before, be sure that in your Form.Designer.cs code file, that each call to your custom controls are done so as absolute calls. For example:
Namespace.CustomControl control;
Rather than
CustomControl control;
Look at your references and find any that have exclamation point icons. Remove the bad references and add them back to your project.
Have you tried disabling UAC completely (running IDE as Administrator + disabling UAC just in case).
Also - always use Fusion Log for tracing assembly loads! See http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.71).aspx for how to set it up
Did you rebuild your components from scratch?
Are the projects included?
Are they all building?
Are they all building on the same platform (x86 vs x64)?
Set the default built to x86 and that should fix it.
Clean the solution
Build the project containing the Control
Add the control to the toolbox/form
See if this works.
For anyone who with similar issue(s). I just came across this in VS 2013 (VB side) on an x86 PC. As mentioned above, I toggled from 'anyCPU' to 'x86' and the form designer opened right up. Simple, but probably wouldn't have tried it without the above post(s). For what it's worth, I toggled back to 'anyCPU', and as yet have had no recurrences...
I faced the same error, can't able to Build my application.
So searched here, Says to change the solution platform X64 or X32.
But in my case the Solution platform only shows Any CPU and configuration manager option only
But i simply change the solution configuration.
Debug => Release
then
Release => Debug
Finally clean and rebuilt the solution. Its works for me!!:)
While the top answer from #richard-whitehead is correct that the 64bit editor cannot load the 32bit controls which is why you're seeing the error, there is another way to have Visual Studio edit 32bit GUI controls in a 64bit GUI project as described here:
https://stackoverflow.com/a/26539992/2280961
I use Visual Studio 2008 SP1.
I'm experiencing a boring bug, that sometimes break my compilation processes with something like:
Error 4 'C:\dev(...)\obj\Debug\CSC4B.tmp' is not a valid Win32 resource file (...)
This file doesn't even is shown in the \Debug folder. The only way I can solve this (temporarily) is to restart the machine. It is happening more frequently now.
Do you know how to resolve this issue?
NOTE:
I've searched in many places for resolving this bug. Most places mention something with icons, but I have set no icons to projects in this solution.
The problem was really weird. And the fault was of GDI++, an application that changes the way Windows renders text. After closing this processes, everything is just working fine (except the text rendering).
I'm using Visual Studio 2005 w/.NET 2.0. I have no idea what happened, but all of a sudden I noticed that the Properties window for ALL of the DataGridViews in my project went blank. I've tried dropping in new ones..still blank. I restarted Visual Studio and my computer...still blank. I've done some google searches, and I've found people who have had the same problem, but there is no solution and it appears that Microsoft has been unable to duplicate it. Any ideas?
I created a new project in a new instance of Visual Studio and dropped a DataGridView in there, and it worked..then I checked my other project in the other instance of VS and the Properties can back for my DataGridViews. Fluke or solution? No idea.
I have had similar problems where my property windows go blank. It tends to happen when your machine is using a lot of UI resources or your toolbox is trying to update its list of controls.
Check to see if your control is being selected by your property window at the top of the property window screen
Try switching to a different control and then back to force the property window to update
Just close your UI Designer and re open it.
If all else fails, just close and reopen your solution
If it's still a problem you can always reduce how much memory your toolbox/UI designer uses by removing custom control generation in your toolbox window. To do this go to Tools / Options / Windows Form Designer / AutoToolboxPopulate - set to false. Now this will not populate your toolbox with custom controls anymore from your solution.
This same thing happened to me because the full path of the project contained an '&'. When I moved the project to a path that did not have an '&' everything worked.
There was same problem - reason was '&'.
I had a bunch of similar problems with Visual Studio UI doing wacky things. I figured it had to do with memory consumption (not a lack of machine memory). Jetbrains made a wrapper here that has solved a lot of my problems in Visual Studio 2005.