I'm using function CDC::Rectangle and it uses logical coordinates.
But I want to know how large is the area on which I draw, so I can for example draw rectangle 10% of area width.
How can I get dimensions of coordinate system from CDC?
Believe it or not, a Windows device context does not keep track of the boundaries of the object it's attached to. GetBoundsRect might give you something useful, or it might not, depending on the circumstances. Using the CWnd object and calling GetClientRect is the most reliable way.
Use GetClientRect to get the client size of the window (ie the drawing space for your window).
Logical coordinates are important only when your mapping mode is not MM_TEXT, in that case you would need to use CDC::LPtoDP.
You should be able to use the example in the link in your question except that
instead of rect.DeflateRect(20, 20);
use rect.right /= 10; rect.bottom /= 10;
Related
My windows c++ program creates EMFs (Enhanced Metafile Format) to export to clipboard, word and excel.
The following example code generates an EMF rectangle (width=height=25) that is only 12x12 while the canvas is 25x25 (note: screen resolution of my laptop is3600x1800).
At other screen resolutions, similar scaling anomalies occur (too big/too small).
It would appear the scaling of the graphics-drawing needs to be set as a function of the resolution.
I clearly have a gap in my knowledge here...any help is appreciated.
HDC ref_dc = GetDC(NULL);
Rect r(0, 0, 25, 25);
Metafile* emf = new Metafile(ref_dc, r, MetafileFrameUnitPixel, EmfTypeEmfPlusDual, L"Drawing");//to HDC
Graphics* g = new Graphics(emf);
//draw a simple box
Gdiplus::Pen* pen = new Pen(Color(0, 255, 0), 1.0f);
pen->SetDashStyle(DashStyleSolid);
pen->SetLineCap(LineCapRound, LineCapRound, DashCapFlat);
g->DrawRectangle(pen, r); // DrawMyObject(g);
// code here to put on clipboard
Although unrelated to your actual problem, I feel very compelled to point out that your programming style of creating all the objects on the heap is quite odd. There is no reason to use new like this. Just create temporary objects on the stack. This keeps you from leaking memory and other resources like a sieve. By way of illustration, all you need is this:
// Create Graphics object
Graphics g(emf);
// Draw a simple box
Gdiplus::Pen pen(Color(0, 255, 0), 1.0f);
pen.SetDashStyle(DashStyleSolid);
pen.SetLineCap(LineCapRound, LineCapRound, DashCapFlat);
g.DrawRectangle(pen, r);
// g and pen automatically go out of scope here, implicitly calling the destructor
// and freeing their resources. No need to call delete.
As for your actual question, metafiles don't have a fixed size. They basically just encapsulate a series of GDI drawing instructions that can be recapitulated at will.
The normal way to put an enhanced metafile on the clipboard would be to call SetClipboardData function, using the CF_ENHMETAFILE format. The handle type would obviously then be HENHMETAFILE. You'll need to get GDI+ to give you one of those, probably by using the Metafile::GetHENHMETAFILE method after you've finished loading/creating your metafile object.
The scaling/sizing is the responsibility of the client code, the one that receives your metafile from the clipboard and tries to display it. The metafile header contains an entry that specifies its horizontal and vertical resolution. That can then be scaled in terms of the display DPI. In GDI+, something like:
Graphics g(...);
Metafile mf(L"MyFile.emf");
MetafileHeader mfh;
mf->GetMetafileHeader(&mfh);
REAL xScale = mfh->GetDpiX() / g.GetDpiX();
REAL yScale = mfh->GetDpiY() / g.GetDpiY();
g.ScaleTransform(xScale, yScale);
Self Answer:
The Graphics is created with a 'new' because it must be destroyed
before the EMF is 'written'. Else the emf does not 'record' the steps performed in by the Graphics object. Perhaps we should put an extra set of braces, but that would be equally awkward. According to the documentation: "The recording ends when the Graphics object is deleted or goes out of scope." Hence the explicit new(s) and delete(s). The EMF get pushed to the clipboard post destruction of Graphics and prior to destruction of EMF.
*The mistake/problem appears to be caused by using the constructor for the EMF that includes Rect struct as an argument. The Rect dimensions appears to have no discernible relationship with graphcs object coordinates used for drawing, and thus it crops the resultant EMF in unpredictable ways. Using a constructor with only an HDC or an HDC and a filename solves this problem, at least in my hands.
Last, adding the code lines
REAL xScale = mfh->GetDpiX() / g.GetDpiX();
REAL yScale = mfh->GetDpiY() / g.GetDpiY();
g.ScaleTransform(xScale, yScale);
provides a base scaling such that the emfs are more or less similar size regardless of screen resolutions. This is quite useful to give a consistent/reasonable default size for exports on the user side.
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.
I have been using directx for a while now and one thing that has always bothered me is that windows are squares (I guess this applies to most programs). Now as creation often happens by defining a rectangle shape and drawing that, black for example. I have been thinking of 2 approaches to this:
Define a bigger rectangle and draw parts of the background transparent.
I decided not to go for this one as I have absolutely no idea how to do this.
See what microsoft offers when it comes to window shapes.
And while they did have a lot of win32 configuration settings (no border etc) I couldn't find anything about drawing in a particular shape (like using a triangle for example).
Does anyone have experience with window shapes or drawing a background transparent? Maybe even a better option that I missed? Thanks in advance!
This can be done quite simply using the SetWindowRgn API call. What this does is define the area within which the system will allow drawing to appear.
As a simple example, lets punch a hole in one of our windows. The following can be done in the WM_CREATE handler of the window:
case WM_CREATE:
{
// Get the window rect
RECT r;
GetWindowRect(m_hwnd, &r);
MapWindowPoints(NULL, m_hwnd, reinterpret_cast<LPPOINT>(&r), 2);
// Work out the size of the window
LONG w = r.right - r.left;
LONG h = r.bottom - r.top;
// Create a rectangular region to cover the window (almost)
HRGN hRgn = CreateRectRgnIndirect(&r);
// and a smaller elliptical window
r.left += w/4;
r.right -= w/4;
r.top += h/4;
r.bottom -= h/4;
HRGN rgnCirc = CreateEllipticRgnIndirect(&r);
// Now we combine the two regions, using XOR to create a hole
int cres = CombineRgn(hRgn, rgnCirc, hRgn, RGN_XOR);
// And set the region.
SetWindowRgn(m_hwnd, hRgn, TRUE);
}
break;
Some important notes. The region that is passed to SetWindowRgn is from that point on owned by the system, so do not perform any more operations on it. Also, you would need to modify the region if the window is resized - I only put the example in WM_CREATE as... an example.
Another little caveat about the above, it doesn't perform the calculation of window size correctly... as I said, this is just an example that punches a hole in a window.
Finally, I tried it with a simple Direct-X program, and it works with that too. Hoorah!
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.
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.