Thanks for that link... actually it doesn't tell me why I should use one or the other. There table in that page lists two differences between CArray and CStringArray: 1. The former uses templates while the latter doesn't - well, that is obvious. 2. CArray isn't type safe while CStringArray is - but I fail to see why. A CArray<CString, LPCTSTR> can only contain CString objects, so what should be type unsafe? So actually, my question remains open :-( Regarding your advice, I have to deal with tons of old code. Many parts of that code work well with Unicode, but I know some places that confuse bytes with characters, and I sure don't know all of them, and I just don't have the time to clean everything up. I will have to live with a mix of 16 and 8 bit character strings. Besides, it is a pity that there is no built-in or MFC UTF-8 string type in C++. I love Perl for that.

Well in fact I should use proper terminology. When I said "ANSI" I meant 8-bit character stuff. When I said "Unicode" I meant 16-bit characters. Speaking of Unicode code points, mostly in the range 0000 through 007f. In other words, ASCII characters in different representations. But this discussion is getting beside the point. My question was, what is the advantage of CStringArray over CArray<CString, LPCTSTR>? Rephrase: Why is there a CStringArray class when CArray<CString, LPCTSTR> has the same functionality? Or does it not?

You can subtract two pointers of the same base type, and the result is the number of elements of the base type that fit between the addresses which the pointers hold. Likewise, you can add an integer value to a pointer, and that will result in the address of a data type instance so and so many steps above the original pointer. Confusing? - Take your example:

int a[]={5,10,15,20};

Assume a starts at address 0x00040000. This is also the address of a[0]. In C, a is the same as &a[0]. a+1 is &a[1] or 0x00040004, and a+2 is &a[2] or 0x00040008. &a[2]-2 is &a[0] or 0x00040000. When x-y==z is true, then x-z==y should also be true; when &a[2]-2==&a[0] is true, then &a[2]-&a[0]==2 should also be true. The C language is nice enough to fulfil this. To calculate the number of bytes between two memory locations, convert the pointers to BYTE* like this:

(BYTE*)&a[2]-(BYTE*)&a[0]

This would evaluate to 8, as you expected. Assuming, of course, that 'int' is a 32-bit integer type.

From the MSDN documentation of DeleteFile:

If the function fails, the return value is zero (0). To get extended error information, call GetLastError.

GetLastError returns an error code which you can convert into a string via the FormatMessage function. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms680582%28v=vs.85%29.aspx[^] for an example. One possible reason might be that you are trying to delete the same file more than once.

There are situations when I must support ANSI, for example when it comes to dealing with ANSI text files or serial protocols. I want to have the CStringArray functionality available for the must-be-ANSI situations while generally compiling for Unicode. Btw, I find MFC containers quite useful (unless, of course, you are using STL). The documentation is quite good, and you can debug-step through the source code.

Hi, I am wondering what might be the advantage of CStringArray over CArray<CString, LPCTSTR>. The background is that I am planning to implement a CStringArray-like template class which is either explicitly ANSI or explicitly Unicode, and would like to implement it as CArray<CStringA, LPCSTR> and CArray<CStringW, LPCWSTR>, respectively. Thank you for any comments. Hans

Hi CPallini, thanks for your input... this is demo code, the production code uses more aggressive memory allocation. Doubling seems a bit of overkill to me; I start with like 1024 bytes and add steps of 1024. The point of adding just 10 is to show that the algorithm works and is not the cause of the problem. About ReleaseBuffer() - omitting it, in my understanding, may confuse CString operations but should not make an API call fail should it? :^)

Superman, that was a superfast and supergood answer. It works :) Thanks!

Is there a way to find out whether a rectangle or a point (given in screen coordinates) is contained in any monitor currently attached to the system? The background of my question is this: During shutdown, my dialog based MFC application stores its current screen coordinates in the registry. When I open the application the next time, it fetches the coordinates and moves the window to where it had been during the most recent session. If I move the dialog to my secondary monitor and close it, then unplug the monitor and restart the application, the dialog displays itself on an invisible part of the desktop :^) . In this case, I'd prefer to use the default location - the center of the primary monitor.

Tried to boil the code down to the relevant parts.

void ReadAllSections(const CString &sFileName, CStringArray &arrsSections)
{
static const DWORD k_dwBufferInc = 10;
DWORD dwBufferSize = 0, dwReturnedLength;
CString sBuffer; // using a CString as a buffer to simplify memory housekeeping

// try to read the section names; increase buffer and retry if too small
do
{
    dwBufferSize += k\_dwBufferInc;
    dwReturnedLength = GetPrivateProfileSectionNames(sBuffer.GetBuffer(dwBufferSize - 1), dwBufferSize, sFileName);
}
while (dwReturnedLength == dwBufferSize - 2);

arrsSections.RemoveAll();

if (dwReturnedLength == 0)
{
    // dwLastErr is 0 if the file or directory don't exist, or if it exists and contains no sections.
    // Sometimes, on a Vista Home PC, 8 is returned, although the file exists and contains sections.
    DWORD dwLastErr = GetLastError();
    AfxDebugBreak();
    return;
}

// split buffer into section names (I know this part could me more sophisticated)
LPCTSTR pszCurrent = sBuffer;
while (\*pszCurrent != \_T('\\0'))
{
    arrsSections.Add(pszCurrent);
    pszCurrent += \_tcslen(pszCurrent) + 1;
}

}

Let me point out once more that the AfxDebugBreak(); statement is not always executed, although always the same file name (and absolute directory) is used, and the same file is used (and exists) all the time. The MSDN documentation does not mention that a return value of 0 means failure, nor that GetLastError() should be called in that case.

I recently observed that a call to the GetPrivateProfileSectionNamesA WinAPI function returned 0. Postings on the internet suggest to check file existence, Windows INI file mapping, etc. To make the story short: The call works reliably after a Windows restart, and eventually fails (using the same INI file, and file name) after several program runs, where "fails" means "returns 0." The documentation does not indicate that GetLastError() returns anything useful in this case, but I called it nonetheless, and it returned 8 (ERROR_NOT_ENOUGH_MEMORY). That was the first time ever I worked with Vista Home, so I am wondering whether Vista Home has any limitiations with respect to memory or other resources, compared to XP Pro or Vista Pro where this problem never appeared. It may be that some resources used by third-party software are not released after a program crash - and the program crashed rather often during my testing/debugging sessions. Thanks for any suggestions - Hans

Thanks to all who helped me. I finally found a solution. 1. Insert the ON_WM_NCPAINT() macro into the dialog's message map, and create an overwritten OnNcPaint method. 2. In OnNcPaint, first call the derived OnNcPaint method, then get the paint DC by calling GetWindowDC(), and paint into the DC whatever you want to paint. That's it. It is a good idea to exit the function before painting if IsWindowVisible() returns false, or if IsIconic() returns true, because there is no visible title bar to paint on. If you don't want to paint over the close, minimize, etc. icons, you can retrieve their positions by calling GetTitleBarInfoEx. This function is unfortunately not defined in CWnd, so you must define it as

BOOL GetTitleBarInfoEx(HWND hWnd, PTITLEBARINFOEX pstInfo)
{
return ::SendMessage(hWnd, WM_GETTITLEBARINFOEX, 0, (LPARAM)pstInfo);
}

GetTitleBarInfoEx will return FALSE unless running Vista and up, so you must check its return value and call GetTitleBarInfo if the call to GetTitleBarInfoEx is not successful. GetTitleBarInfo is a member of CWnd :-) If you want to put a flashlight on the title bar, create a timer event which changes a flag (which indicates whether the light is on or off) and then calls RedrawWindow(NULL, NULL, RDW_FRAME | RDW_INVALIDATE);. This will post the WM_NCPAINT message. What I wrote is for CDialog derived classes. I read (but I haven't tried it) that for MDI applications, you must insert this functionality into the main frame.

modified on Friday, June 18, 2010 3:50 AM

Thanks emilio_grv, that does make a change. Now the hdc isn't always 0. However, just calling GetDCEx and ReleaseDC (with no code between them) makes the window update so slow that most of the time, parts of the window are not properly redrawn...

It didn't really help. I assume the sample code should go into an override of CWnd::DefWindowProc, so I tried this:

/*virtual*/ LRESULT CMyDlg::DefWindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
if (message == WM_NCPAINT)
{
LRESULT lRes = CDialog::DefWindowProc(message, wParam, lParam);
HDC hdc = ::GetDCEx(GetSafeHwnd(), (HRGN)wParam, DCX_WINDOW|DCX_INTERSECTRGN);
// Paint into this DC
if (hdc)
{
CDC dc;
dc.Attach(hdc);
CBrush brush(HS_FDIAGONAL, RGB(255, 255, 255));
dc.FillRgn(CRgn::FromHandle((HRGN)wParam), &brush);
}
::ReleaseDC(GetSafeHwnd(), hdc);
return lRes;
}
return CDialog::DefWindowProc(message, wParam, lParam);
}

A breakpoint on the 'if (hdc)' line would be hit but a breakpoint on the 'CDC dc' line wouldn't, so hdc seems to be 0 all the time :-( Anyway, thanks for the reply!

modified on Saturday, April 24, 2010 3:52 PM

Is it possible to add icons to a dialog window's title bar? I'd like to add some LED-style status indicators to a dialog-based MFC application which should be shown next to the close/maximize/minimize icons. I imagine it's to do with non-client area painting but I couldn't find sample code. I don't want to create the whole title bar - there are examples around for that - but just add an icon or a bitmap.