Since you are using nonstandard nomenclature, please define Root Window, Sub window and Child window. What is relationship between all windows? In general message about gaining focus (by any means including mouse click) is sent to a window that is gaining focus and loosing focus. If this window is a child window, the parent does not know about what child gained focus. You have two choices: write code in the child window to notify parent window about gaining focus using custom defined message, or write windows hook that will receive messages before any window does and post a message from the hook procedure to a parent window. In both cases you would pass a handle to a window that gains focus.

JohnCz

This is definitely the best approach. I wish I could rate your post.

JohnCz

Superman: I respectfully disagree. quote: "The messages for keystrokes are WM_KEYDOWN and WM_KEYUP These are directed to the parent dialog containing the control." Unless dialog does not contain any controls, dialog window never gets focus, hence WN_KEYDOWN and WM_KEYUP messages are not sent to a dialog. quote: "and then subclass the control from the InitDialog function of the dialog class using the SubclassDlgItem method." It is possible to use SubclassDlgItem or SubclassWindow but it would be much easier to let the wizard do subclassing, by simply add variable of the CRichEditCtrl and later replace it with the derived class type. ForNow: Depending what is exactly you are trying to achieve, I think the best way to handle special keys is creating accelerators and add handlers to a CRichEditCtrl derived class.

JohnCz

The question is: what view? Is it MFC Cedit or CrichEdit derived view? Anyway, you do not have capture anything. Where is the word capture coming from? Windows sends messages that you choose to handle or not you do not have to set any traps to capture. Anyway, if this is MFC application it has menu items and possibly corresponding accelerator keys combination with the same ID. For example: ID_EDIT_PASTE has Ctrl-V or CTRL-Insert key combinations. If you want to completely disable copying pasting, insert do nothing (empty) handlers for those IDs, leave accelerators intact and remove appropriate menu items. If you want to disable editing under certain condition, use Update UI for those commands.

JohnCz

I am not sure why check for valid password in OnInitDlg, while it seems that it should be checked before main dialog is invoked. No need for posting any messages to the thread. Besides, log in dialog should not be checked for cancel only but validate password and/or username. This code snippet shows how this can be done:

CLoginDlg loginDlg;
loginDlg.DoModal();
INT\_PTR nResponse = loginDlg.DoModal();

if(nResponse == IDCANCEL)
{
	return FALSE; // canceled exit app, terminate
}

if(loginDlg.m\_csUser.CompareNoCase(lpszUser))
{
	return FALSE; // no match exit app, terminate
}

if(loginDlg.m\_csPassword.Compare(lpszPassword))
{
	return FALSE; // no match exit app, terminate
}

CMainDlg dlg;
m\_pMainWnd = &dlg;
INT\_PTR nResponse = dlg.DoModal();

.
.
.

JohnCz

THe code snippet assumes UNICODE is being used. I would suggest to use generic mapping that will work for both: ANSII and UNICODE: As for retrieving parts of the path why not to let CRT do it for you using generic (_tsplitpath_s)? For example:

LPTSTR lpszPath = \_T("project.config.user");
TCHAR szFilename\[MAX\_PATH\] = {0};
TCHAR szExt\[MAX\_PATH\] = {0};

\_tsplitpath\_s(lpszPath, NULL, NULL, NULL, NULL, szFilename, \_MAX\_FNAME, szExt, \_MAX\_EXT);

JohnCz

I know it is an old thread, but I think it is worth to explain the problem. You wrote console application. Console does not process any messages, hence your GetMessage (as you pointed) is blocking the thread since it waits for the message to come. There is no messages to handle and you are sitting in the GetMessage without ever exiting. Put a break point in the message loop and see if it is ever hit.

JohnCz

Hi yogeshs, You have to learn how to be patient and read all answers and documentation without skipping some parts. I have already mentioned twice: If you are using VS 2008 with feature pack or with SP1 use CMFCButton class. You need Visual Studio SP1 installed. Web installer[^] ISO image[^] Than you can subclass button using CMFCCustButton. Subclassing is easy if you use wizard: Right click on the button in the resource editor and choose Add Variable. The only option you have is CButton, so select it. After wizard closes, open dialog’s header file and change CButton to CMFCMenuButton.

JohnCz

That is not guaranteed. It may also depend on SDK version you are using for build. Compiler will flag errors if header files contain #ifdef with specific versions of windows around some functions to exclude definition for certain versions of Windows. So, you may have some help in finding out what is excluded for XP but you may still be left with some unknowns to resolve on your own.

JohnCz

You are welcome, glad to be of help.

JohnCz

OK, that is good so far. If you have SP1 installed, why not to follow my previous advice (from my earlier response): If you are using VS 2008 with feature pack or with SP1 use CMFCButton class. To set button face color, call SetFaceColor member. You have to set m_bTransparent to FALSE anf disable teaming by calling EnableWindowsTheming member and passing FALSE as parameter. This is much easier than reinventing a wheel.

JohnCz

Toolbar with treeview? What kind of toolbar you are referring to? Are you sure you are creating a toolbar? Maybe it is a tool window? Could you please post a snippet showing how you create this toolbar.

JohnCz

Another thing to check: Is your project using targetver.h? If yes, change constants to define 0x0500 to target Windows XP. If not, make sure you define WINVER, _WIN32_WINNT and _WIN32_WINDOWS as 0x500 in stdafx.h before any include. Compiler will then flag all errors coming from usage of the functions that are not defined in XP.

JohnCz

Couple of things to consider: Is your project set for minimal rebuild? Are you using precompiled headers? If answer to any of the above is no or I don’t know check the following: Open the project's Property Pages dialog box. Click the C/C++ folder. Click the Code Generation property page. Make sure the Enable Minimal Rebuild property is set to yes(/Gm). Click on Precompiled header folder. Make sure that Create/Use Precompiled header is set to Use. . . (/Yu) Make sure that Create/Use PCH. . . is set to stdafx.h You may also need to check all source files iif they are set for precompiled header use. You can turn this on/off for every file in the project. Close the solution and delete .suo, .ncb files and Debug/Release directories, this will delete .idb (dependencies info file). Load the project and choose rebuild. Also check if any file in the project has the modification time set ahead of you local date/time (this may have been already addressed in one of the posts).

JohnCz

yogeshs, I think you are confusing two things: Windows window with MFC object that is not a window. MFC object encapsulates window handle and only after window handle is valid, such an object represent Windows window. There are three ways to make MFC object alive (assign a valid handle): Calling member function Create for a given class Calling Attach Subclassing window Only calling Create and Subclassing will allow MFC object handling messages of the attached window. Calling Attach will not allow process any messages processing, since window procedure has not been replaced by the object’s window procedure. You should post a snippet that shows a function where it assert. Your code snippet does not make much sense since the meaning of the GetDlgItemId is unknown. Regardless, it looks like you are trying to attach an object that is already alive, meaning Windows window has MFC object attached to it. MFC code does it for you. Please answer one question that I have already asked: What version of Visual Studio you are using? Maybe taking it from here will be more beneficial for you.

JohnCz

Hi, Where is your code? Another thing: Could you lease refrain from using cryptic code like "ur ref means"? I would really appreciate it, since to understand it I need translation to English.

JohnCz

on-btn-click event is not an event. It is a handler for WM_COMMAND message and BN_CLICKED notification code receives as message parameter. Are you by any chance handling WM_LBUTTONDOWN or WM_LBUTTONUP? If yes, do you call base class handler? You should perform all custom drawing in DrawItem function. Is it a case?

JohnCz

I do not think that UpdateWindow addresses the original problem. UpdateWindow triggers system to sends (not posts) WM_PAINT message, therefore message is not placed in the queue. SendMessage causes system to call windows procedure directly, therefore this s a blocking call. Anyway, original problem is to update UI controls on the ribbon, not list control. Setting variable using proper synchronization is I think less expensive than posting the custom message from the worker thread; however I think the difference is negligible. If PostMessage is used, the handler can set variable to be used in Update UI handlers.

JohnCz

MSDN states also (below the line you have quoted): "By default, the DefWindowProc function selects the default system colors for the button. Buttons with the BS_PUSHBUTTON, BS_DEFPUSHBUTTON, or BS_PUSHLIKE styles do not use the returned brush. Buttons with these styles are always drawn with the default system colors. Drawing push buttons requires several different brushes-face, highlight, and shadow-but the WM_CTLCOLORBTN message allows only one brush to be returned. To provide a custom appearance for push buttons, use an owner-drawn button. For more information, see Creating Owner-Drawn Controls." This is also incorrect, as you can see from the sample code at the bottom. Radio and check boxes use static background color. If you change styles to "push like" color of the face will also not change. As you can see parent window is not able to change button’s face color of the pushbutton. In conclusion, MSDN is incorrect (not the first time).

JohnCz

Actually is not as easy as it looks. Unless you really need to retrieve localized version info size, use GetFileVersionInfoSize instead GetFileVersionInfoSizeEx. GetFileVersionInfoSize is available starting with Windows 2000. You do not have to call LoadLibrary and GetProcAddress since your module (exe) is linked implicitly with Version.lib. To write robust code you would have to write more than simple GetProcAddress. If you really want to use both, depending on the operating system, you will have to retrieve proc address depending on OS version and load appropriate procedure address, since Version.lib contains both: ASCII and UNICODE versions of the functions. If your app is built as ANSII you would have to use ANSI version of the function: GetFileVersionInfoSizeExW or GetFileVersionInfoSizeW depending on what system your app is running on. For unicode build you will have to explicitly request UNICODE versions: GetFileVersionInfoSizeExW or GetFileVersionInfoSizeA. Something like this:

//#define _USE_EXPLICIT
void GetFileVersionLenInfo()
{
OSVERSIONINFO osvi = {sizeof(OSVERSIONINFO)};
DWORD dwHandle = 8000;
DWORD dwVer = 0;
GetVersionEx(&osvi);
HINSTANCE hInst = NULL;

#ifdef _USE_EXPLICIT

typedef DWORD (CALLBACK\* lpfnGETFILEVERSIONINFOSIZEEX)(DWORD, LPCTSTR, LPDWORD);
typedef DWORD (CALLBACK\* lpfnGETFILEVERSIONINFOSIZE)(LPCTSTR, LPDWORD);
//typedef UINT (CALLBACK\* LPFNDLLFUNC1)(DWORD,UINT);

hInst = LoadLibrary(\_T("VERSION.dll"));

if(osvi.dwMajorVersion > 5)
{

#ifdef UNICODE
lpfnGETFILEVERSIONINFOSIZEEX lpfnGetFileVersionInfoSizeEx = (lpfnGETFILEVERSIONINFOSIZEEX)GetProcAddress(hInst, "GetFileVersionInfoSizeExW");
#else
lpfnGETFILEVERSIONINFOSIZEEX lpfnGetFileVersionInfoSizeEx = (lpfnGETFILEVERSIONINFOSIZEEX)GetProcAddress(hInst, "GetFileVersionInfoSizeExA");
#endif // UNICODE

	dwVer = lpfnGetFileVersionInfoSizeEx(FILE\_VER\_GET\_NEUTRAL, 
		\_T("C:\\\\Program Files\\\\Beyond Compare 2\\\\BC2.exe"),
		&dwHandle);
	return;
}

#ifdef UNICODE
lpfnGETFILEVERSIONINFOSIZE lpfnGetFileVersionInfoSize = (lpfnGETFILEVERSIONINFOSIZE)GetProcAddress(hInst, "GetFileVersionInfoSizeW");
#else
lpfnGETFILEVERSIONINFOSIZE lpfnGetFileVersionInfoSize = (lpfnGETFILEVERSIONINFOSIZE)GetProcAddress(hInst, "GetFileVersionInfoSizeA");
#endif // UNICODE
dwVer = lpfnGetFileVersionInfoSize(
_T("C:\\Program Files\\Beyond Compare 2\\BC2.exe"),
&dwHandle);

#else
dwVer = GetFileVersionInfoSize(
_T("C:\\Program Files\\Beyond Compare 2\\BC22.exe"),