|
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.
|
|
|
|
|
|
It didn't really help. I assume the sample code should go into an override of CWnd::DefWindowProc, so I tried this:
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);
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
|
|
|
|
|
hummm .... see the comments at http://msdn.microsoft.com/en-us/library/dd145212%28VS.85%29.aspx#CommunityContent[^]
Looks like MSDN didn't tell the whole story:
Just copied from the user commnt
Getting the device context when handling WM_NCPAINT does not work as described. Additional undocumented flag 0x10000 has to be used:
case WM_NCPAINT:
{
HDC hdc;
hdc = GetDCEx(hwnd, (HRGN)wParam, DCX_WINDOW | DCX_INTERSECTRGN | 0x10000);
ReleaseDC(hwnd, hdc);
}
(Verified on Windows XP)
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
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...
|
|
|
|
|
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
|
|
|
|
|
I understand the scientific term, but I don't know how to avoid them.
I've always allocated memory with pointers/new and deallocated them with delete variable.
Suddenly started getting buffer overrun yet my allocations are accurate and addressing is accurate. 
|
|
|
|
|
|
Hi, two tips straight from our C++ coding standard:
- don't guess the size of a memory block when reading or writing. Never ever.
- use data containers (
STL) when ever possible, avoid manual memory allocations with new and delete
Generally I use STL or my own buffer/string classes instead of dealing with low-level memory handling, for example std::vector<unsigned char>. It is just too easy to miscalculate an array size, even a single byte too less can give you a memory exception in production code, not even speaking about the possibility of code injection via a buffer overrun. If I see new/delete in a code review I get very suspicious.
That's just my personal design philosophy, hope it helped.
/M
|
|
|
|
|
How did you determine if are having buffer overruns? Using a tool? Your program is crashing? You get memory leaks? This is important to determine how to detect the problametic code.
Also just to state the obvious if there are no allocation or deallocation problems then you can't have any memory related problems. So the fact that you do have buffer overrun means that there must be a problem somewhere. I know it is bit pedantic but it is important to say it aloud.
-Saurabh
|
|
|
|
|
I don't actually know what you're trying to do with this, but a pretty common mistake is miscounting the number of elements you're trying to allocate, so while you might think you've allocated accurately, you could be one off, which causes lots of problems.
For example:
"Phil Collins"
Has a total of 13 elements, even though there's actually 12 characters in "Phil Collins". A common mistake is to forget the '\0' character at the end of every C-style string, so the whole thing is thrown off. (BTW, I used "Phil Collins" because I named a tree after him in a video game I'm working on... Does Phil Collins work as a good name for a tree..? )
I hope that helps; bits of source code would probably help though.
*I can haz a cookie?*
|
|
|
|
|
Hi, I have a HANDLE which is an unnamed pipe, so I can't open it the usual way with fopen.
I want to use stdio functions like fscanf on it, so I'm looking for a way to obtain a FILE* from that HANDLE.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
Never mind, I found out how - _fdopen.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
|
I have C++ Win32 app that uses HttpSendRequest to request some URL (via https). It worked OK earlier; but then errors ERROR_INTERNET_INCORRECT_HANDLE_STATE began happen. Why these ones? Any ideas?
|
|
|
|
|
Hi,
googling for ERROR_INTERNET_INCORRECT_HANDLE_STATE (which you should have done already) I stumbled on this[^] which might apply.
|
|
|
|
|
hi all
i m working With RAPI functions.
sometimes CeRapiInitEx or CeRapUnInit function not returns the pointer.
please tell me how can i resolve this.
thanks in advance.
|
|
|
|
|
|
debug cursor or pointer not return when execute CeRapiInitEx
|
|
|
|
|
the eagle flies at midnight
|
|
|
|
|
I thought it was Balrock and NoName[^] that started at midnight?  Not to mention the bimbos they have on. 
The wonderful thing about the Darwin Awards is that everyone wins, especially the members of the audience.
|
|
|
|
|
hi friends
please me any body.........
how to convert CString Unsigned short and short to CString
|
|
|
|
|
|
Richard MacCutchan wrote: atoi()[^].
Yet better _ttoi (the generic text mapping routine), so you don't have to make changes to the code for an Unicode build. Do I get the nitpick cookie?
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: Do I get the nitpick cookie?
No, but I get the "you forgot about MBCS/Unicode" cookie. 
It's time for a new signature.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
Now with 29% more Twitter
