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.
Related
I want to detect on which screen a window is displayed when I got its handle. I found a SetWindowPos() function in Win API, but unfortunately there is no GetWindowPos() just a GetWindowRect(), but this results some odd values.
I got two devices, left one 1280x1024 and right one (primary) 1680x1050. When I want to get the position of a minimized firefox, I get b/l/r/t -31973/-32000/-31840/-32000 for either screen.
How do I know that it is my left or my right screen?
WinAPI has a MonitorFromRect function, which is probably what you need. I'm not sure if there's a C# equivalent, but you can call it through interop.
Be aware that the window can be on both monitors, or on neither. The API has flags for that, e.g. MONITOR_DEFAULTTONEAREST.
Try GetWindowPlacement, in order to find the rectangle that the window will use if it were restored.
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.
So I have tried searching for the better part of a day for the answer to a simple question. I want my C# application to popup another winform on a timer and then close it after a delay. Simple enough, done and done. Now my issue is that I want it to actually be on top of other applications UNLESS they are full screen. By that I mean a true full screen application such as a game. I do not want to interfere with such an application since it should take priority over my application.
The issue is that I am using the 'OnTop' property on the popup form and, while it works perfectly for any other applications I have been testing it while playing a full screen game and the form, when it "Show()"s, takes the full screen application and drops it into windowed mode.
Is this the intended effect of the 'OnTop' property with full screen applications? If so is there a way that I can have my form popup on top of normal windowed windows and not interfere with full screen applications?
Any links, example, a kick in the general direction is great. The only hits that I come up with when searching for winforms involving full screen is people trying to get their application into full screen or having their application take focus away from another application.
Thanks on advance.
(I didn't post any code due to it just being a simple winform that is "formX:Show()" on a timer with the "onTop" property set)
(EDIT) So thanks to awilson53 for putting me on the right track I was able to find a method (albeit somewhat picky) to determine if an application is full screen. Seems kinda simple, and an "well duh", answer after all is said and done.
95% of the credit goes to the author of the article: http://www.richard-banks.org/2007/09/how-to-detect-if-another-application-is.html
~5% goes to awilson53 for getting me on the right track. :)
Check out this wrapper for the EnumWindows function. This will allow you to enumerate all open windows and determine their window state. You will want to check the EnumWindowItem.Maximized property, and if it is true set your OnTop property to false. If none of the EnumWindowItem's return Maximised you can set OnTop to true.
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)
How can I print screen minimized windows? I believe it's possible, since Windows task-bar can create a preview of a window even if it is minimized.
This guy managed to do exactly what you are after: http://www.codeproject.com/Articles/20651/Capturing-Minimized-Window-A-Kid-s-Trick
I know this question is really old, but it can still be valid for someone.
I'm pretty confident that this is not possible, at least by an external application like yours. When an application window is minimized, the window cannot (and does not) receive WM_PAINT messages, meaning that it is impossible to ask the window to redraw itself while it is minimized (or, "take a picture of it"). This is a limitation (or a rule) of the Windows API.
The taskbar "gets around this" by displaying a cached image (which is the last snapshot the DWM took of the window before it was minimized) and so it is not in fact taking a current picture of the window. You can test this by running an application which periodically updates itself, and then minimizing it -- you will see that the preview image will not be updated until it is restored.
The only way you could get around this is to do what the taskbar does -- periodically take a picture of the window you want, and when it is minimized, use the cached image instead. Of course, this means your app will have had to have been following the target window some time in advance (this obviously won't work if the first time you want to take a snapshot of the window is while it is minimized).