I am facing this strange issue. I built a C# application in Windows 7. It was showing the proper icon for the exe file, that I had set. I tested in other windows 7 systems, no issues so far.
When I moved the exe file to an Windows XP system, it was not showing the icon, but rather the default icon ( icon similar to a floppy disk).
Any idea what could be the reason ?
Thanks
on XP, the max icon size is help in HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics
On my system, Shell Icon Size is set to 33
You may change it to larger values, but there will be a slightly longer delay as windows loads in the appropriate size icon
There is apparently no limit, but having icons of 1024x1024 would be a little excessive (not to mention the loading time required)
Related
I use 2560x1440 monitors scaled on Windows 10 to 125%. I wrote a C# unit test case in Visual Studio 2019 that calls a DLL to 1) find the window handles of various apps (notepad, wordpad, etc) and 2) resize them to just under 100% of the monitor size. I used Win32.MoveWindow to do the move, like so:
// MoveWindow(hWnd, left, top, width, height)
Win32.MoveWindow(hWnd, 0, 0, 2500, 1400, true);
The problem is that while debugging in the unit test, Windows10 scales up the 2500 and 1400 pixel numbers by 125% and moves the windows to that larger size. The windows then hang off the bottom and right edges of the screen.
In contrast, when I run the same DLL code from a skeleton Windows Forms app (and while not debugging), the code works fine, and Windows resizes the Notepad and Wordpad app windows correctly.
I pass in the same numbers to Win32.MoveWindow in both cases.
In case it matters, for the DLL code, I have tried endless combinations of the app.config and app.manifest settings for my DLL code that calls Win32.MoveWindow (and am targeting NET 4.7.2) but without success.
For the skeleton Forms app, I have tried 4.6.1 and 4.7.2 with no DPI settings in app.config and the "dpiAware=true" enabled in the app.manifest. (Of course, neither the skeleton Forms app nor the DLL are DPI aware. I just tried the setting on and off.)
The only thing that seems to make a difference is whether I am debugging. I expected that I could use the normal screen pixels from the OS screen boundaries when I did MoveWindow operations, but that isn't working well when debugging.
What is the proper way to resize other apps with Win32.MoveWindow? Should my app determine the current scaling factor and then down-scale the numbers that I pass to Win32.MoveWindow? (I would pass 2500/1.25 = 2000 to Win32.MoveWindow, for example, for 125% scaling.)
Is the debugger supposed to interfere with scaling and sizing like this? Is it a known problem?
#selbie was totally correct and exactly on the target with his comment. He was even kind enough to bold one of the key statement lines for me to draw my attention to it. #selbie made it easy for me to solve the problem. I have included my test code fragments below.
Windows Behavior
As #selbie pointed out, if 125% scaling is enabled in the Accessibility Settings to make everything bigger, Windows reports different screen sizes to aware and unaware processes.
For DPI-aware processes, Windows will report 2560x1440 because they are supposed to down-scale their thinking so that Windows can scale it back up 125% to produce sharp text, etc.
For DPI-unaware processes, Windows will report 2048x1152 to the caller so the caller thinks the screen is smaller than it really is. Windows scales up the caller's orders by 125% to make the caller's sizes fit the hardware screen size (2560x1440).
The Problem
The problem I had was that my unit test code (DPI unaware) was using the hardware sizes in my DLL code (2560x1440), obtained from a database and not the OS, so when Windows scaled it up, my relocated windows were bigger than the hardware screen size.
When the same DLL was used in a DPI-aware Forms app, Windows allowed for everything (produced no net scaling up) and the relocated windows fit the hardware screens.
The Solutions
The first solution is to make your calling process DPI-aware so that you can use the hardware screen sizes in your code. Do this by calling the Win32 API in NET 4.6 and above. This is what I used in my unit test to make it work properly.
[STAThread]
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern bool SetProcessDPIAware();
static void Main() {
if (Environment.OSVersion.Version.Major >= 6) SetProcessDPIAware();
... either ConsoleApp code or Windows.Forms code here
}
The second solution is to enable DPI-awareness in the EXE app.manifest file. Just uncomment the default XML code in the default app.manifest file produced by AddNew in Visual Studio.
APP.MANIFEST FILE
<application xmlns = "urn:schemas-microsoft-com:asm.v3" >
<windowsSettings >
<dpiAware xmlns = "http://schemas.microsoft.com/SMI/2005/WindowsSettings" >
true </dpiAware >
</windowsSettings >
</application >
In NET 4.7 and above, you can also use the new PerMonitorV2 DPI settings in the app.config file, not the `app.manifest' file. This apparently lets you use different DPI-awareness for different monitors. (I have not tried this yet, but I mention it here for completeness.)
<configuration>
<!--requires NET 4.7, and the default is false />
<System.Windows.Forms.ApplicationConfigurationSection>
<add key="DpiAwareness" value="PerMonitorV2" />
<add key="EnableWindowsFormsHighDpiAutoResizing" value="false" />
</System.Windows.Forms.ApplicationConfigurationSection>
</configuration>
My WPF application's font suddenly looks different on my PC. I am not sure if this occur after a windows update. I am using Windows 10 Version 1803, .Net 4.5 in one application and .Net 4.6.1 in the other. This is happening on my 2 WPF applications.
Here is a picture of my WPF application on other PCs (Acceptable):
https://ibb.co/444D8X5
Here is a picture of same WPF application on my PC (Unacceptable):
https://ibb.co/mvVHT9s
Any clue why this is happening? Looks like the characters moved a couple pixels down. Thanks in advance.
So the reason your font doesn't appear at runtime is because it is not actually installed on your machine. Windows doesn't know where to find it so it goes to a default font. You should embed the font within the application.
See this post
I'm currently building a wpf application and am looking for a "generic" looking set of icons like they are used in windows explorer, they can be something between xp and 10 style as long as I have a consistent set of icons in .png format for functions like: new file, open, save, save as, send to, undo, redo, ...
Is there a way to use the windows internal once?
Or a way to get some from the internet?
I tried the VS2015 Image Library but the icons there have different resolutions and colors. I couldn't even find a pair for undo/redo with the same resolution/color.
Here's the list of dlls that you can get icons from on any windows OS:
%systemroot%\system32\imageres.dll - contains lots of icons, used almost everywhere in Windows 10. It has icons for different types of folders, hardware devices, actions, and so on.
%systemroot%\system32\shell32.dll - also has lots of icons used in various parts of Windows 10. Together with imageres.dll , shell32.dll hosts one of the largest icon collections in Windows 10.
To get the complete list of dlls check out this article.
A tester was having a look at my silverlight app and his results were nothing like I expected. After some discussion I found out that the difference stemmed from his setting his operating system to use huge icons. This changed the look and feel of my application.
How, in the C# code of my silverlight, can I query the Operating System to ask if the user has choosen to use huge icons, medium icons, or small icons?
Maybe
System.Windows.Icon.SizeProperty
?
It sounds like your tester may have different DPI settings on their machine. The different DPI settings will result in images/icons appearing very unexpectedly scaled.
Try adding the following code when the app starts up:
Application.Current.Host.Settings.EnableAutoZoom = false;
I have a WPF application rendering fonts to a larger size than I expect.
The catch is that only WPF applications I write seem to have this effect, and the problem happens only on one computer. The effect also happens with all WPF programs I write (not just one), and all windows exhit the effect.
I am using Visual Studio 2008 with .NET 3.5 SP1; all programs written in WPF.
The operating system is Windows XP with the latest service packs.
The screen resolution is 1680x1050.
Windows and buttons using Windows XP style.
Font size is Normal.
DPI setting is normal size (96 dpi).
I tested my applications on a two other computers with same OS and settings and it looks fine. My programs run on dozens of other computers and I do not see this problem.
Here is a window that looks good:
Here is a window that shows the problem (notice the button on the lower left, and the font size):
I know I can increase the width and add margin to compensate, but I need to understand why this happening.
I am close to a release and I want to make sure my users do not see this effect.
All ideas appreciated.
I'm not running XP right now, but I thought you could customize the size of the text that appears in window captions (and buttons) via the Display Properties (right-click desktop, select Properties, and it's the 3rd or 4th tab, I think). It lets you select colors for selected items, background colors of windows, etc.
That would be separate from setting the DPI settings.
This looks like an unholy XP feature. It had the option to change the size of the system font independently from the video adapter DPI setting. Very convenient to XP users living in Easy Asia where glyphs that make up the letters are very intricate and need all the pixels they can get to make their script legible.
It is covered by Windows Forms with the Form.AutoScaleMode property, which defaults to Font instead of Dpi. WPF is however strongly biased to Dpi, the normal way of scaling.
I don't think the twain shalt ever meet. Tell your user to reset the XP setting. It is buried somewhere in the Control Panel + Display setting, I don't have it anymore to tell you exactly where to look. Or the logical alternative, changing the video DPI setting to match the font size. That's was in the Adapter tab, IIRC. Changing it from 96 to 120 DPI would be a good guess.