Hi!

One of the possible solutions - overload OnCmdMsg() in your child dialog:

BOOL CTaskItemDlg::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)

{

// First chance: standard command processing

if ( CDialog::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo) )

return (TRUE);

// Second chance: reroute processing to parent window

CWnd* pOwner = GetParent();

if ( NULL != pOwner )

{

if ( pOwner->OnCmdMsg( nID, nCode, pExtra, pHandlerInfo ))

return (TRUE);

}

return (FALSE);

}

If you have more complicated scenario, like ICBM had you can set owner window of CTaskItemDlg to your top-level dialog and add third chance rerouting to OnCmdMsg:

CWnd* pOwner = GetOwner();

if ( NULL != pOwner )

{

if ( pOwner->OnCmdMsg( nID, nCode, pExtra, pHandlerInfo ))

return (TRUE);

}

These ensures that your top-level dialog/Task panel will receive at least button clicks. To handle complete range of messages you will probably need to overload OnWndMsg().

Best regards.

A bit more time thinking and I decided it was laziness on my part trying to avoid writing specific classes for each of the TaskPanel Dialogs. In the end the classes are tiny anyway, it's a whole lot more managable and easier in the long run. Also has the advantage of being able to derive task panel dialogs from the resize dialogs so the task panel dialogs can be made to correctly resize (as they do in windows explorer search dialogs). Perhaps that should be in the Task Pane sample.

ICBM - I ended up doing almost the same to get the message up to the parent but with only a single GetParent() as I handle the messages in the task panel control rather than in it's parent dialog.

I also noticed the tab thing which is an annoyance. It only tabs around the controls within the panel dialog. That's either an oversight or a bug since regular custom controls will happily tab through as required.

I had the same problem. I wanted to have the parent window handle a particular button press, but could not get it to go. I ended up with this utterly hideous hack:

void CNameTPDlg::OnBtnSearchClicked()
{
static const UINT FJ_SEARCH_BTN_CLICKED = ::RegisterWindowMessage(_T"FJ_SEARCH_BTN_CLICKED"));

// Ugly !
GetParent()->GetParent()->SendMessage(FJ_SEARCH_BTN_CL ICKED);
}

The secondary problem, which I have not attempted to solve, is that the TAB key will only tab around the dialog box controls. You must physically click outside the area of the dialog box to send the focus elsewhere in the application. The sample app that codejock supplies (their search app) has exactly the same problem.

The "Task Panel" sample illustrates how to use a child dialog as the content of a task panel group. That's great and I have that working just fine using the example TaskPanelDlg class to handle colouring as in the example. I can see how you might roll your own TaskPanelDlg classes to wrap up processing of the child dialog's controls and then notify the parent when required. However, I only want to use the child dialogs so I can lay out the controls how I need them in resource editor and this particular task panel is simple enough to handle all control messages itself. So the question is... how do I go about getting the task panel window to handle messages from child dialogs created as controls.

The obvious comment is (as suggested in MFC help) that the child window commands (e.g. ON_BN_CLICKED) are passed to the parent in the absence of a handler but this does not seem to be the case.

Thanks