How does one get the screen resolution of the current monitor? By "current monitor", I mean the one that the application starts on.
The reason I ask this is because I have two monitors, the secondary monitor is 1280x1024 and the primary is 1680x1050. The application, when it starts, stupidly sets its own height and width based on the primary monitor resolution. When the application launches on the secondary monitor, it overflows the resolution, which looks strange.
I know I could change/remove the code that sets the application's height/width, but I am also curious how one determines which monitor the application is showing on.
For what it's worth, I am not a proponent of applications that set their own height/width.
Use Screen.FromControl:
Screen.FromControl(this).Bounds
where this is the Form that you want to retrieve the Screen information for.
Related
I want to access the DisplayInformation class from a background task in my UWP that takes an image and resizes it from its native resolution to the size of the user's screen, so that it can be set as a wallpaper.
However, when I attempt to use DisplayInformation.GetForCurrentView(), an exception is thrown, saying that the method must be called from a thread associated with a CoreWindow. How can I avoid this?
Any solution will work as long as it will give me the complete width and height of the user's screen in raw pixels.
This API requires a CoreWindow because you could have multiple monitors on your system, and it needs to know which one to pick (it picks the one that is currently showing the window). The best solution is to query the properties when your foreground app is running, and then save them for later use. (Of course this won't be perfect if the user has two or more monitors of different sizes and you pick the "wrong" one, or they upgrade the monitor, etc. but it's the best you can do).
I am trying to write a program for re-configuring displays in the cases where a display loses connection, and Windows is not able to correctly reconfigure its prior settings.
Usually if you unplug a monitor, Windows seems to keep track of configuration settings for the display. Example, I have three monitors hooked up right now. If I unplug my "main display", Windows will make one of the remaining two monitors the main display. Then if I reconnect the monitor, Windows will usually remember the configuration for that monitor, specifically in this case that it was my main display, and set it appropriately.
I am currently using EnumDisplayDevices, EnumDisplaySettings, and ChangeDisplaySettingsEx to set the configurations for each monitor (resolution, orientation, etc). However, looking at what information EnumDisplayDevices and EnumDisplaySettings populate the DISPLAY_DEVICE and DEVMODE structs with, nothing seems to be able to uniquely identify the monitors themselves. I'll get values that will uniquely identify each display from each other for the current configuration (\.\DISPLAY1 and \.\DISPLAY2 \.\DISPLAY3, for example), but if I unplug the monitor that had the identifier \.\DISPLAY1, next time running I'll get the values \.\DISPLAY1 and \.\DISPLAY2. So that value can't be used to unqiuely identify a specific monitor later on.
Is there some piece of unique information about each monitor hooked up that I can use to identify them? My feeling that such a piece of information might exist comes from the fact that most of the time if I unplug a monitor and plug it back in, Windows will retain its configuration.
The wmimonitorid class accesses more H/W specific data than EnumDisplaySettings, in particular, the SerialNumberID which should be unique (at the very least) to the entire range of monitors from a specific mfg.
The field is a Uint16 array, so can be read in with code similar to that provided in this answer.
Also try DeviceID in the Win32-PNPEntity class, for PnP monitors. Can be retrieved in a WMI query based on pseudo code like:
SELECT * FROM Win32_PnPEntity WHERE ClassGuid={4d36e96e-e325-11ce-bfc1-08002be10318}
I have a secondary monitor that I want to use exclusively to display information from a specific c# wpf application.
The normal windows desktop should not extend to this monitor, it should be impossible to move the mouse to it or somehow transfer input focus to this monitor. Nor should there ever be any error messages or other windows on that monitor, except for the single maximized window from the c# application.
This is necessary because the secondary monitor is used to display information not to the user in front of the pc, but to a remote location several meters away.
The approach I found to maximize a wpf app on a secondary monitor requires that the windows desktop is extended to that secondary monitor. If that monitor is not visible to the user, then this can get highly confusing if the mouse cursor is on that monitor, or an error message or main window is accidentally moved to it.
Is it possible to somehow get exclusive access to a monitor in wpf without extending the windows desktop to that monitor?
I want to move a Window (HWND) in a second monitor. The thing is that I tried many things like double the resolution or putting negative values and it never was able to put the window on my second monitor.
Any clue of how to do that in C/C++/c#
Screen and the Form.StartPosition should get you there.
See the first answer to this post (for C#/WinForms solution): How do I ensure a form displays on the "additional" monitor in a dual monitor scenario?
The desktop layout is user-configurable, a second monitor can be to the left, to the right, above, below, or positioned weirdly compared to the primary.
The GetMonitorInfo function will help you find out where the second monitor is, in virtual screen coordinates. As #holtavolt mentioned, the .NET Screen class is a convenient wrapper.
Users complain that when they have several minimized windows in MDI container it's impossible to distinguish them unless they resore each. I wonder if it's possible to make minimized window a little bit wider so the text in the caption can contain 6 characters?
Thanks in advance!
No, this is not possible. Windows determines the width of a minimized window using the current system parameters, and there's no way to change this dynamically for a single application without changing the values across the entire system.
Specifically, the default size of all minimized windows is 160x31. In a MDI application, you actually get to see this size because the window is minimized into its MDI host, rather than into the Windows taskbar. Raymond Chen (a developer on the Windows Shell team at Microsoft) published a couple of blog entries a while back that explain why this particular size was chosen, and what it means. The first is available here: Why do minimized windows have an apparent size of 160x31? And the second follow-up entry can be read here: No, really, why is it 160x31? As he explains in that second post:
The width of the miniature title bar is determined by the iWidth member of MINIMIZEDMETRICS structure. You can retrieve and change this structure with the help of the SystemParametersInfo function. (Use the SPI_GETMINIMIZEDMETRICS and SPI_SETMINIMIZEDMETRICS flags, respectively.) Some people will mention the MinWidth registry value, but those people are wrong. Notice, for example, that messing with MinWidth requires a logoff cycle, whereas using SPI_SETMINIMIZEDMETRICS takes effect immediately. That's because SPI_SETMINIMIZEDMETRICS updates the internal state variables, whereas whacking the registry just change a value in a database that nobody pays attention to once you've logged on.
What about the height? That's just the height of a caption bar, which you can adjust from the Appearance tab of the Display control panel. (Programmatically, you can use that helpful SystemParametersInfo function, this time using the iCaptionHeight member of the NONCLIENTMETRICS structure.)
Since I doubt your users really want you messing with their default system parameters by P/Invoking the SystemParametersInfo function, you aren't left with a whole lot of options. My recommendation, especially if they're working with a single window at a time and leaving the others minimized, is to switch to an alternative interface. The intention of MDI was to allow users to tile or cascade multiple windows so that they could see more than one at a time. Since it sounds like that's not the typical use case, you might both be better served by switching the application to use tabs instead. This is often called a tabbed document interface (TDI), a somewhat more modern implementation of the old multiple document interface (MDI). It's become quite popular over the years; check out the Wikipedia article.
[Although this post is 11 years old, i'm trying...:
I'm facing an issue with in-app minimized windows, which are broken on my Windows11 (certainly by a software, but I don't know which one...). Those in-app minimized windows are much more narrower that it should be. Instead of having the minimized title bar containing title and 3 buttons, I can only see the close button. You said here it wasn't possible to change this size for a unique software, but I assume you know(knew) where to change it for the whole system? Here is a capture of the issue in ultraedit 1 and here in 3dsMax for example 2
To those who have the same problem as me, I found the solution:
(win+r) regedit
HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics
add the string value "MinWidth".
Change the string value named "MinWidth". Set its value using the following formula:
-15*width in pixels
For me, acceptable one was -3300
Little drawback: It also changes size of the minimized windows in the taskbar (make them much wider when there is a few of them in taskbar)