ShowWindow is THE API to use to show and hide windows, if your window does not exist yet, the function will assert. Try making sure that the window you are calling this function on is valid before you call this function. an exmaple of this would be Page::OnInitDialog(); { BOOL ret = CPropertyPage::OnInitDialog(); CWnd *pWnd = GetDlgItem(IDC_MY_WINDOW); if (!pWnd || !::IsWindow(pWnd->GetSafeHwnd()) { ASSERT(FALSE); } else pWnd->ShowWindow(SW_HIDE); // or whatever you want to do with it. } Did you use classwizard to generate control variables for your window objects? /yawar

use CWnd::ShowWindow function to show or hide them.

I said "try overloading".. that was not right, I meant "try writing message handler for"... :):):):)

try overloading WM_NCHITTESTmessage, the code will look something like this UINT YourClass::OnNcHitTest(CPoint point) { int ret = YourParentCwndBasedClass::OnNcHitTest(point); if (ret == HTCAPTION) { if (GetAsyncKeyState(VK_LBUTTON) < 0) { if (!mbLButtonDown) { TRACE("\nDown"); mbLButtonDown = true; } } else { if (mbLButtonDown) { TRACE("\nUp"); mbLButtonDown = false; } } } return ret; } where mbLButtonDown would be a bool member of your class and would need to be initialized as false when constructing your window. There might be some other way to do this too, this was just a quick thing that came to my mind. HTH, /yawar

use ::SHGetSpecialFolderLocation or SHGetSpecialFolderPath function. with folder parameter as CSIDL_COMMON_DESKTOPDIRECTORY (for all users) or as CSIDL_DESKTOP (for currently logged in user). Functions are declared in Shlobj.h /yawar

:) glad to have helped.. have fun /yawar

I think I need to provide a little explanation of my response too, look at the expansion of ON_MESSAGE macro in AFXMSG_.H file #define ON_MESSAGE(message, memberFxn) \ { message, 0, 0, 0, AfxSig_lwl, \ (AFX_PMSG)(AFX_PMSGW)(LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM))&memberFxn }, Anything you put in ON_MESSAGE macro has to have this declaration, the compiler generates the code and assumes that your function will have a return type of LRESULT and will take two parameters, WPARAM and LPARAM. If you declare return type different or make parameters different, you will end up corrupting the stack and hence the crash in release mode. answer to question that why this won't crash in debug mode is simple, the debug executable has a lot of guard bytes before and after function calls, those bytes get corrupted but stack does not. Probably if the target function signature would be too big (20+ parameters) it will crash in debug too. Let me know if this was the reason. I have gone in too much detail without even knowing if your bug really was because of bad function signature. Ciao, /yawar

what is function signature of your OnInitDialog member, if it is anything other than LRESULT OnInitDialog(WPARAM wParam, LPARAM lParam) the application is bound to crash in release mode. Remember, OnInitDialog function is provided as a virtual function in CDialog already, and if you want to handle the WM_INITDIALOG message yourself, you need to at least name it differently, the way you are doing it, you are probably declaing it as virtual BOOL OnInitDialog(); /yawar I have no signature

Hi, I need a little help here from the community members, I'll appreciate if you share any information about this problem if you saw it and tried to fix it or actually fixed it. The product I am working on invloves OpenGL APIs, but 1) On Windows XP 2) and on all kinds of Graphics cards we have (Nvidia, Wild Cat) here at the office Windows desktop tooltips get completely garbled after a call to wglMakeCurrent function. As soon as the window whose DC was used in wglMakeCurrent call is destroyed, the tooltips come back. By tooltips getting garbled, I mean that hovering mouse over program buttons in the taskbar would show wrong information for running programs, the tooltip window's size would be either smaller than the size the tooltip's text can fit in, or too much large showing the extra area as shadow or black color. Any hints.. ideas? Yawar