How do you get the height and width of a CWnd*? The CWnd is the window correct? Why isn't the command:
CWnd* parent = this->GetParent(); // C++ command
parent->GetSize(); // what I think the method should be OR ...
parent->GetWindowRect(); // what i think it should be (no arguments)
what is this LPRECT? I already have the object ... why and what is the argument going into GetWindowRect? What am I pointing to? I already have the object i want to find the size of ... just give me the size.
The LPRECT parameter is a pointer to a RECT structure (the "LP" prefix actually stands for "long pointer", for historical reasons).
The GetWindowRect function is going to retrieve the window rectangle for your CWnd object, but it's going to do so by filling in a RECT structure with those coordinates. Therefore, you need to create a RECT structure and pass a pointer to it to the GetWindowRect function.
It is worth mentioning that the API accepts a pointer to a RECT structure for full compatibility with Win32. The CRect MFC class actually inherits from the RECT structure defined by the SDK, so you can use a CRect object interchangeably here. Which is nice, because CRect provides member functions that make it easier to manipulate rectangles.
Sample code:
CWnd* pwndParent = this->GetParent();
CRect rc;
pwndParent->GetWindowRect(&rc);
// rc now contains the rectangle of your window!
Note that the GetWindowRect function will return the screen coordinates of your window. This is usually not what you want, unless you're trying to reposition the window on the screen. Screen coordinates are tricky to work with because they are relative to the entire virtual screen, which can have negative coordinates in a multi-monitor configuration. Also, if you try and determine the size of the window using its screen coordinates, you'll get the entire size of the window on the screen, including its non-client areas (like the title bar, the min/max/close buttons, etc.).
What you normally want instead are the client coordinates of a window, retrievable by calling the GetClientRect function in an identical manner. This time, we'll use a RECT structure, just because we can:
CWnd* pwndParent = this->GetParent();
RECT rcClient;
pwndParent->GetClientRect(&rcClient);
The answer is you use GetWindowRect.
CWnd* parent = this->GetParent();
CRect size;
parent->GetWindowRect(&size);
If you are asking why it is done like that, I can think of two answers:
MFC is very old (older than some of the people reading this I suspect). Compilers couldn't handle returning structures by value in those days. Since then "backwards compatability".
MFC is (or at least, was originally) a very thin wrapper over the Windows API functions.
okay, I figured out my answer I believe. Here for anyone who cares to know ...
CRect rc_total_window;
this->GetWindowRect(rc_total_window);
where 'this' is a CWnd* object. Thanks again for all the history and explanation. It helps to know why things are the way they are so you can be sure that you aren't doing something wrong; especially helps when the methodology is different than what was learned in modern language courses.
Related
How can I determine if a RECT area inside of my window is covered by other windows (occluded). I mean, if the user can see this RECT area or not?
I could not find the right answer to this question. In fact, I should define a function with a signature like this
bool isWindowPartVisible(HWND handle, RECT rect)
Inside this function, I am allowed to use only the Windows API function.
One way is to use WindowFromPoint() for sufficient number of points in that rect and check if it's YOUR window.
I have a mode less dialog that I have changed the shape into a roundrect using SetWindowRgn(). I would like to draw a colored border around it using FrameRgn. Here is the code I am using
BOOL CMyDlg::OnInitDialog()
{
CDialog::OnInitDialog(); m_Brush.CreateSolidBrush(RGB(255,255,255));
CRect rcDialog;
GetClientRect(rcDialog);
// This Creates area assigned to Dialog: This goes directly below the above in OnInitDialog
m_rgnShape.CreateRoundRectRgn(rcDialog.TopLeft().x, rcDialog.TopLeft().y,rcDialog.BottomRight().x,rcDialog.BottomRight().y, rcDialog.Width()/8, rcDialog.Height()/8);
::SetWindowRgn(GetSafeHwnd(), (HRGN)m_rgnShape, TRUE);
return TRUE; // return TRUE unless you set the focus to a control
// EXCEPTION: OCX Property Pages should return FALSE
}
void CMyDlg::OnPaint()
{
CPaintDC dc(this); // device context for painting
CBrush brush;
brush.CreateSolidBrush(RGB(255,0,0));
dc.FrameRgn(&m_rgnShape, &brush, 2, 2);
}
Can anyone explain why the FrameRgn is not working, and maybe provide some sample code here
that will make it work.
As shown in the CWnd::SetWindowRgn documentation:
After a successful call to SetWindowRgn, the operating system owns the
region specified by the region handle hRgn. The operating system does
not make a copy of the region, so do not make any further function
calls with this region handle, and do not close this region handle.
What this basically means is that you can't then go and use the region for another purpose, and you also can't "lose" the region. As it's a member variable, this last issue isn't a problem you need to worry about. But regarding the "do not use it" part, you will notice that the FrameRgn(...) call most likely returned zero, indicating the failure when trying to draw.
What you can do is to detach the region handle from the CRgn object and use that to set the window region, then you can recreate a new one as before:
m_rgnShape.CreateRoundRectRgn(...);
HGDIOBJ hRgn = m_rgnShape.Detach();
::SetWindowRgn(GetSafeHwnd(), (HRGN)hRgn, TRUE);
m_rgnShape.CreateRoundRectRgn(...);
For a better description, have a look at this article which covers Setting a Window Region, to make it look like a cat.
Edit: Your comment mentions that now, the framed region is effectively offset by an amount. The amount is likely to be the size of the border of your window.
When you call GetClientRect, it returns the size of the client area of the window - the part you can easily draw on, and the part that is "described" by the device context when you do CPaintDC dc(this); in your OnPaint() method.
The reason for the offset is that your window has a border, which you don't normally draw on (there are ways, but we'll ignore those for now). So the device context describes an area that's offset from your window.
The simplest solution to this in your case is likely to be to modify the dialog template to specify no borders. This will of course limit resizing the window, but as you've already set a region, I'm assuming resizing isn't an option either.
In Windows XP and above, given a window handle (HWND), how can I tell if the window position and size leaves the window irretrievably off screen? For example, if the title bar is available to the cursor, then the window can be dragged back on screen. I need to discover if the window is in fact visible or at least available to the user. I guess I also need to know how to detect and respond to resolution changes and how to deal with multiple monitors. This seems like a fairly big deal. I'm using C++ and the regular SDK, so please limit your answers to that platform rather than invoking C# or similar.
Windows makes it relatively simple to determine the size of a user's working area on the primary monitor (i.e., the area of the screen not obscured by the taskbar). Call the SystemParametersInfo function and specify the SPI_GETWORKAREA flag for the first parameter (uiAction). The pvParam parameter should point to a RECT structure that will receive the coordinates of the working area in virtual screen coordinates.
Once you've got the coordinates that describe the working area, it's a simple matter of comparing those to the current position of your application's window to determine if it lies within those bounds.
The desire to support multiple monitors makes things slightly more complicated. The documentation for SystemParametersInfo suggests that you need to call the GetMonitorInfo function instead to get the working area of a monitor other than the primary. It fills in a structure called MONITORINFOEX that contains the member rcWork that defines the working area of that monitor, again expressed in virtual screen coordinates as a RECT structure.
To do this right, you'll need to enumerate all of the monitors a user has connected to the system and retrieve the working area of each using GetMonitorInfo.
There are a few samples of this to be found around the Internet:
MSDN has some sample code for Positioning Objects on a Multiple Display Setup.
If you're using MFC, here's what looks to be an excellent example of multiple monitor support.
Even if you're not using MFC, that article refers the following link which looks be a real gem as far as explaining how multiple monitor supports works in Windows, even if it's a little bit old school. Like it or not, very little of this has changed in later versions of Windows.
Finally, you mentioned wanting to detect resolution changes. This is much simpler than you probably imagined. As you know if you've done any Windows programming, the primary way that the operating system communicates with your application is by sending messages to your WindowProc function.
In this case, you'll want to watch for the WM_DISPLAYCHANGE message, which is sent to all windows when the display resolution has changed. The wParam contains the new image depth in bits per pixel; the low-order word of the lParam specifies the horizontal resolution and the high-order word of the lParam specifies the vertical resolution of the screen.
You can use MonitorFromRect or MonitorFromPoint to check if window's top left point or bottom right point isn't contained within any display monitor (off screen).
POINT p;
p.x = x;
p.y = y;
HMONITOR hMon = MonitorFromPoint(p, MONITOR_DEFAULTTONULL);
if (hMon == NULL) {
// point is off screen
}
Visibility check is really easy.
RECT rtDesktop, rtView;
GetWindowRect( GetDesktopWindow(), &rtDesktop );
GetWindowRect( m_hWnd, &rtView );
HRGN rgn = CreateRectRgn( rtDesktop.left, rtDesktop.top, rtDesktop.right, rtDesktop.bottom );
BOOL viewIsVisible = RectInRegion( rgn, &rtView );
DeleteObject(rgn);
You don't have to use RectInRegion, I used for shorten code.
Display, resolution change monitoring is also easy if you handle WM_SETTINGCHANGE message.
http://msdn.microsoft.com/en-us/library/ms725497(v=vs.85).aspx
UPDATE
As #Cody Gray noted, I think WM_DISPLAYCHANGE is more appropriate than WM_SETTINGCHANGE. But MFC 9.0 library make use of WM_SETTINGCHANGE.
I'm writing an unmanaged Win32 C++ function that gets a handle to a bitmap, and I need to draw on it.
My problem is that to draw I need to get a device context, but when I do GetDC (NULL), it gives me a device context for the WINDOW! The parameter for GetDC () is a window handle (HWND), but I don't have a window; just a bitmap handle.
How can I draw on this bitmap? Thanks!
In addition to Pavel's answer, the "compatible with the screen" always bugged me too, but, since CreateCompatibleDC(NULL) is universally used for that purpose, I assume it is correct.
I think that the "compatible" thing is related just to DDB (the DC is set up to write on the correct DDB type for the current screen), but does not affect read/writes on DIBs.
So, to be safe, always use DIBs and not DDBs if you need to work on bitmaps that doesn't just have to go temporarily onscreen, nowadays the difference in performance is negligible. See here for more info about DIBs and DDBs.
CreateCompatibleDC() and SelectObject() your bitmap into it.
However, not every bitmap can be selected into any DC.
You might have to play with mapping mode and other options of memory DCs.
The basic win32 paradigm for drawing on a bitmap is that you select the bitmap onto a device context, after which, all drawing operations on that device context are stored in the bitmap. You then use one of the various 'blit' operations (e.g. StretchBlt) to transfer this to a display surface, which is just the device context of a window client area.
Others have provided better detail, this is just the high-level view.
Well, this is a bit outside the box.. I guess.. But I do know that Graphics can return a HDC, and Graphics take a Bitmap as an argument to its ctor . A Bitmap in turn can be created from a HBITMAP and a HPALETTE. The only problem here is that I do not know if the HPALETTE argument can be NULL.
Graphics* g;
Bitmap* bitmap;
HBITMAP _bitmap; // <- this one is yours
bitmap = Bitmap::FromHBITMAP(_bitmap, NULL);
g = new Graphics(bitmap);
HDC hdc = g->GetHDC();
// when done, call g->ReleaseHDC(hdc);
However, I would urge you to receive the HDC as an argument to your function as well.. I do not think that anyone will have a BITMAP and NOT have the DC to it.
If you're having these issues with finding a HDC to a HBITMAP, so will everyone else.
Where should I be looking for resolution of DirectX (3D) device? getViewport seems to have Width and Height, yet as far as I know viewport is supposed to be an area, not 2D "canvas" with these attributes.
(I hope "resolution" applies to the device, not D3D directly. Please correct me if this part is wrong.)
Simple MSDN link will be good answer as well, however I already browsed it through and couldn't find it.
Edit: it seems like getDisplayMode will work for fullscreen apps that changes resolution since it returns the display adapter mode, yet I'd like to be able to get the size of d3d window too.
DirectX doesn't actually own a window. If you remember when you initialise the device, you give it a handle to a window. It takes this and displays to its viewports within this window.
So if your looking specifically for the window size then you'll want to get it at the OS level.
This question discusses how to deal with it.
Namely GetWindowRect/GetClientRect(HWND, LPRECT)
If for some reason you only have the d3d interface, you can use getcreationparameters to get the original hwnd and then you can use GetWindowRect or GetClientRect as suggested before.
D3DDEVICE_CREATION_PARAMETERS cparams;
RECT rect;
device->GetCreationParameters(&cparams);
GetWindowRect(cparams.hFocusWindow, &rect);
//rect.width
//rect.height
Perhaps this is what you need: IDirect3D9::GetAdapterDisplayMode Method
http://msdn.microsoft.com/en-us/library/bb174316%28v=VS.85%29.aspx
If you want the window size then call "GetClientRect" on the hWnd you are setting up with.