The GetClientRect function, according to MSDN, is actually only good for determining the client width & height, since left & top are always zero. Is there a way to get the complete client coordinates, including left & top (either in screen space, or in window space)?
Call ClientToScreen on the top left and bottom right of the returned RECT. If you're using MFC, CWnd has a helper overload of CWnd::ClientToScreen that will do this transparently for you.
Maybe you are needing GetWindowRect.
You're looking for the GetWindowPlacement function. This function returns a WINDOWPLACEMENT struct which has an rcNormalPosition property which specifies the window's position when it is in the normal (rather than maximized or minimized) display state.
EDIT: itowilson's answer is actually cleaner because the WINDOWPLACEMENT structure also contains a bunch of data you don't need.
Related
I need the ability to set the window not only z-type (always top/always bottom/etc.), but also z-index (0..+inf.).
Windows with smaller z-index values should be lower than windows with greater.
I know about SetWindowPos and it`s parameter hWndInsertAfter, using it I can achieve what I want, but this way seems too complicated.
Is there better solution ?
The windowing subsystem maintains the Z-Order, implemented as a list:
The system maintains the z-order in a single list.
You can move windows in this list (by calling SetWindowPos for example), passing the previous window as an index, or HWND_TOP to move a window to the front. There is no API that uses an ordinal as the index.
If you need to insert a window ahead of another window, call GetNextWindow(GW_HWNDPREV) first to be passed as the hWndInsertAfter. If there is no window ahead in the z-order, GetNextWindow returns NULL, which conveniently maps to HWND_TOP.
I needed to find out the height of the screen in order to resize a dialog. I am calling GetSystemMetrics with SM_CYFULLSCREEN and I am getting a certain number (1028 in my case). Per MSDN:
To get the coordinates of the portion of the screen not obscured by
the system taskbar or by application desktop toolbars, call the
SystemParametersInfo function with the SPI_GETWORKAREA value.
I called SystemParametersInfo as well to see what it returns and I get a different number for the height, 1050. Running spy, the area without taskbar is indeed of height 1050. Does anyone know why the different heights? Thanks
From the MSDN docs for SM_CYFULLSCREEN:
The height of the client area for a full-screen window on the primary display monitor, in pixels.
Relevant detail bolded, the client area is the part of the window without the borders and title bar. It is therefore substantially less than the actual primary screen height. Perhaps you meant to use SM_CYSCREEN instead. SPI_GETWORKAREA returns the available space for the entire window, the outer size, the one you'd pass to CreateWindowEx().
How to find out blink cursor position in windows, from c++? In many cases I need send button click on the position of the blinking cursor, but I didn't find any important function which will take care of that.
OS win 7(64), c++
It is called "caret", cursor is the mouse pointer. You use GetCaretPos() to get its position. But the returned position is relative to the client area of the window that owns the caret. Which probably means that you need to find that window first, use GetForegroundWindow() for that. And don't send button click messages, they are posted so use PostMessage().
Avoid all of this by just using SendInput().
Note that UIPI (the user interface component of UAC) prevents you from poking stuff into a window owned by an elevated process.
GetGUIThreadInfo() is probably your best bet; pass it with idThread = 0 to get the info from the currently active thread, and then check the rcCaret member of the returned GUITHREADINFO structure. You'll then need to use ClientToScreen() with the hwndCaret value to convert client-relative coordinates to screen coordinates.
Note that this only works for apps that use the Win32 caret functions - specifically SetCaretPos(). If an app draws its own caret without using these, you may not get anything meaningful back. (Some apps, like Word, draw their own caret, but still call SetCaretPos so that accessibility aids that need to track the caret can use this technique.)
The rectangle you get back can sometimes be wider than the actual caret. When a bitmap is used for the caret, as is the case for Right-To-Left or Left-To-Right carets that have a little 'flag' attached to the top, you'll get back a rectangle that's a bit wider than the actual caret area, and may need to adjust or otherwise figure out where within this area the actual caret bar is - it may or may not be in the exact middle. Looks like for Notepad++ you should be fine, though.
WinAPI to return Window Resizing Object size (This is the boarder around a window that allows you to resize the window). I just need the number of pixels it takes. (Under Windows 7, it looks like it is about 10 pixels.)
Also, what is the official name for this object?
I am coding in a language call PL/B and placing objects on their window. I am using GetWindowRect to get the window size, now I just need to adjust the size by the Window Resizing Object.
Generally, you're better off looking at GetClientRect and ClientToScreen, rather than trying to use GetWindowRect and trimming off the nonclient portions, but if you're dead set on doing that, try GetSystemMetrics with SM_CXSIZEFRAME and SM_CYSIZEFRAME.
I never knew this, but apparently:
By default, the system reduces a
minimized window to the size of its
taskbar button and moves the minimized
window to the taskbar. A restored
window is a window that has been
returned to its previous size and
position, that is, the size it was
before it was minimized or maximized.
In an application, we want to save the position/size of various windows at exit. This leads to a problem for minimized windows. Our solution is to restore all windows before running the save-state logic, but that just seems hacky. Is there a better way?
How about using GetWindowPlacement?
That returns a WINDOWPLACEMENT structure that contains information about the window's coordinates in the restored position.
Remember that (as Leo Davidson points out in the comments) that you must respect the difference between workspace and screen coordinates. As the WINDOWPLACEMENT documentation explains:
The coordinates used in a
WINDOWPLACEMENT structure should be
used only by the GetWindowPlacement
and SetWindowPlacement functions.
Passing workspace coordinates to
functions which expect screen
coordinates (such as SetWindowPos)
will result in the window appearing in
the wrong location. For example, if
the taskbar is at the top of the
screen, saving window coordinates
using GetWindowPlacement and restoring
them using SetWindowPos causes the
window to appear to "creep" up the
screen.
Or, the simpler solution that I've no doubt used before is just to check if the window is minimized before saving the state, and if it is, skip saving any state information.
As far as explaining why a window changes its size when it gets minimized, Raymond Chen's blog entry (and the linked entry as well) on the subject is mandatory reading. They don't really change to their taskbar button's size, but rather to a pre-defined size of 160x31. He explains that you can see this by minimizing a MDI child window into its parent—that's really its size.
Handle WM_SIZE message. If wParam is not SIZE_MAXIMIZED or SIZE_MINIMIZED, keep window size and position in some varibles. Use these variables when window is closed.