We Keep Coding

DateTimePicker garbled after Windows 10 Creators Update

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.

Visual Studio Code invisible buttons

So I recently have had an interest in learning C# and so I downloaded Visual Studio Code, assuming that it would be the best place to start. The biggest problem at the moment is that everything looks so empty because buttons are invisible. I can still program and things just fine, it's just hard to know what I'm looking at when half of the UI is missing.
Here is a pic of what I'm explaining:
https://i.gyazo.com/a3f8b0ae48c8fcdc15d92c6ce81e34eb.png
As you can see, the UI buttons on the right aren't visible.. If anyone has experienced this bug and has found a fix for it, that would be great! Thanks guys!

I would suggest trying Visual Studio Community Edition instead of Code. It's also free and includes a lot more functionality.

Martins answer is not targeting the original question, so I suggest to remove it. You are seeing invisible icons because of an issue in VS Code that we noticed on some Windows installations. We use SVG icons and sometimes the Windows registry is not having a correct entry for their file type. The fix is documented on our FAQ page (https://code.visualstudio.com/Docs/FAQ):
Open an Administrator Command Prompt.
Type REG ADD HKCR\.svg /f /v "Content Type" /t REG_SZ /d image/svg+xml
Then restart VS Code and things should be good.

How can I programmatically uninstall a font in Windows?

I have tried searching for an answer to this but I cannot find anything on SO which is much to my surprise, I thought for sure this must have been asked in the past...
I have a requirement to remove/uninstall a font from the windows directory using a C# .Net (version 4) application. The font in question is usually found somewhere like: C:/Windows/Fonts
My initial thoughts was that I can just delete the file (using File.Delete(...)), but I am unsure if this is enough? My worry comes from the installation of fonts... if you copy a file to the font folder then you get a dialog saying the font is installing.
If deleting the file is enough then I am happy to do so, or is their a more recommended way that this should be done?
If it makes any difference then the OS is Windows XP and the fonts are custom fonts but I am not sure what the original install method was
As clearly posting on StackOverflow with a tag of C# isn't apparently enough... I want to do this from a C# .Net (version 4) application.

arccording to this http://support.microsoft.com/kb/314960 deleteing the font file should be enough

WebSupergoo.ABCpdf Test application does not work

I recently cleaned up my Windows 7 64-bit PC, and after it ABCpdf8 started giving me an error, when I try to export HTML to PDF.
The error is "Failed to initiate IE compatibility mode: Failed to load all required assemblies."
at WebSupergoo.ABCpdf8.Internal.IECompatibility.Activate()
at line
theID = theDoc.AddImageUrl(input.Text);
of the test application, and I have no idea why, because I did not remove any assemblies from my machine.
If I run the compiled application on another workstation with the same config (Windows 7 64-bit), it works fine. Dependency Walker images showed no difference in DLLs sets from my machine and from another.
How else can I identify the source of the problem?
It is definitely neither a missing DLL, nor the user access to the system folders, because, I checked user rights as well, they're identical on both machines.
I assume that it might be a corrupted registry entry. Is there any way to quickly check the assumption?
It has to be said that, ABCpdf comes as third-party tool within another software, so I cannot contact support directly, but through the main vendor.

I had a similar problem with different behavior on w7 and ws2008, which was solved by using the Gecko engine
doc.HtmlOptions.Engine = EngineType.Gecko;
Note that websupergoo recommends using Gecko rather than IE9 as parts of the IE API it uses have been deprecated. (item 6.29)

When you 'cleaned' your system you may have erased the license key from the registry. Try re-installing your 'other software'.

Problem with "add reference" under Visual C# 2008 Express Edition after switching from XP to Windows 7

I suddenly have a big problem I didn't have before.
In my current project, I want to add a reference to "Microsoft.Office.Interop.OneNote". When I open the .NET tab of the "Add Reference" dialog, the "Microsoft.Office" assemblies aren't available like they used to be; on my machine, the next assembly after "Microsoft.JScript" is called "Microsoft.SqlServer.ConnectionInfo"; no trace of any of the "Microsoft.Office" assemblies. I used to be able to do this under Windows XP, but made the switch to Windows 7 a couple of weeks ago. I don't know whether that has anything to do with it.
I already checked whether the assemblies are installed on my machine, but I found all of the office assemblies safe and sound in "windows\assembly". Oddly enough, the reference to "Microsoft.Office.Interop.OneNote" in a previous project continues to work; I just can't add any new references with the "add references" dialog, as they aren't shown in the list of .NET references anymore.
Any help will be appreciated.
Kind regards,
Rainer

Pardon the perhaps stupid question.
Have you installed MS Office since you switched from XP to windows 7?
I'm only asking because I forgot to install it after the same upgrade and I spent a good half hour last week trying to figure out why my project that used Powerpoint was complaining.

the content of the dialog you see with ´Add Reference´ is actually not loaded from the GAC. It´s some registry-folder settings for visual studio.
Maybe you installed in such a way that the libraries are not part of this set. Then VS will not show them in the dialog.
for more info on how to add entries to your ´add reference´ dialog see
http://support.microsoft.com/kb/306149

I think I have got it. For the benefit of anyone who runs into the same problem, there was an interesting lesson to be learned about some lesser known features of Windows:
The link Marvin mentioned above...
http://support.microsoft.com/kb/306149
...says:
To display your assembly in the Add Reference dialog box, you can add a registry key, such as the following, which points to the location of the assembly
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyAssemblies]#="C:\\MyAssemblies"
where MyAssemblies is the name of the
folder in which the assemblies reside.
So I did just that, replacing "myAssemblies" with "C:\Windows\Assembly".
Nothing happened.
I changed the value of the empty standard key to "C:\Windows\Assembly".
Nothing.
I tried some variations of the theme: double backslashes, ending with a backslash, the return of the son of the backslash. No cigar.
So I tried to work the other way around by trying to copy the necessary dll from c:\windows\assembly into one of the directories that are being watched by the "add reference" dialog. On my machine, these paths are conveniently listed under
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727\AssemblyFoldersEx]
When I tried to copy the dll from c:\windows\assembly, there was no "copy" option in the context menu. Drag'n'drop didn't work either. For this problem, I found several alternative solutions here:
http://geekswithblogs.net/pavelka/archive/2006/05/05/WindowsExplorerAndTheGlobalAssemblyCache.aspx
I opted for solution 2:
Add DisableCacheViewer Registry Key
Another way to disable to create a new dword key under HKLM\Software\Microsoft\Fusion\ with the nane DisableCacheViewer and set it’s [DWORD] value to 1.
After I had done that, I could see the real directory structure below c:\windows\assembly; almost each and every dll has its own subdirectory. As soon as DisableCacheViewer was set, I could
traverse the real directory tree that was hidden under c:\windows\assembly
copy dlls and paste them to one of the directories listed under "AssemblyFoldersEx"
deduce the correct path to my dlls and create a fresh key to that path just below "AssemblyFoldersEx".
Thank you very much to everyone who answered, and a special thanks goes to hannes pavelka, whose blog entry helped to solve my problem.
P.S.: I'm almost certain that I never had to do this under Windows XP. IIRC, all of the interop assemblies were available without this kind of registry fumbling.