0
votes

Working with C++ app, using MFC.

I have an aux dialog that is created as a secondary dialog to the main application dialog. This aux dialog has several buttons etc. as child controls. If I click on the aux dialog background or in its nonclient area, it comes to the top as expected. But if I click on one of the child buttons, the button functions correctly but the dialog doesn't come to the top.

Is there some event I should handle in the dialog to bring it to the top when any child control is clicked? Or perhaps set some property in the dialog that will ensure that happens?

I'm suspicious I need to handle some activate or focus event that I'm not. Or maybe once the children handle the click, it needs to be propagated up? Or the other way around?

EDIT: Additional details answering question in comment:

Main dialog class CMyDlg and aux dialog class CAuxDlg are both derived from CDialog.

A blank dialog resource exists for each; all child controls etc are created programmatically.

class CMyDlg : public CDialog
{
public:
    CAuxDlg *aux;
    ...
protected:
    virtual BOOL OnInitDialog()
    ...
    DECLARE_MESSAGE_MAP()
}

class CAuxDlg : public CDialog
{
    ...
protected:
    ...
    DECLARE_MESSAGE_MAP()
}

Aux dialog is created in main dialog's OnInitDialog() method:

BOOL CMyDlg::OnInitDialog()
{
...
    aux = new CAuxDlg(this);
    aux->Create(IDD_AUX_DIALOG, GetDesktopWindow());
...
}

In the aux dialog resource, all properties are FALSE except for:

  • border: resizing
  • style: popup
  • title bar: true
  • tool window: true
  • use system font: true
1
How to you create the dialog? Is this a modal dialog?Tom Tom
@TomTom : See edits added to original question. It is not a modal dialog. It can be shown/hidden by a button click in the main dialog. It can be in front of or behind any other dialog, including the main dialog. It actually has a child button which can make it topmost if the user desires, but that isn't the default state.MPW
Why do you, use GetDesktopWindow() as Parameter? Normal on give here pointer to the Parent Dialog (= this). That's is the reason why your controls don't know the relation to the main Dialog.Tom Tom
@TomTom : Because if I pass ‘this’, the dialog will be constrained to always be on top of the parent dialog. I wonder if there’s a property I can set to prevent this behavior while still passing ‘this’ ?MPW
I don't understand your problem, for me it doesn't matter whether I click on the dialog or on the control. But can still mangeg the Z-Order of the Dialog with SetWindowPos(&CWnd::wndTop, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_SHOWWINDOW) if needed, after clock on the controlTom Tom

1 Answers

0
votes

All of my custom controls are derived from a custom base class CMyBase. I added a handler to this base class:

ON_WM_LBUTTONDOWN()
...
void CMyBase::OnLButtonDown(UINT nFlags, CPoint point)
{
    CWnd::OnLButtonDown(nFlags, point);
    GetParent()->SetActiveWindow();
}

and ensured that classes derived from CMyBase that handle WM_LBUTTONDOWN also call the base class's handler:

class CMyCtrl : public CMyBase
...
void CMyCtrl::OnLButtonDown(UINT nFlags, CPoint point)
{
    // do stuff here
    CMyBase::OnLButtonDown(nFlags, point);
}

and that seems to have done the trick.

Note 1: As mentioned in the comments on the question, if I add a standard CButton or CStatic or even CWnd to the aux dialog, clicking on that standard control does bring the aux dialog to the top. I don't know what the standard controls are doing that mine is not (other than elaborate mouse handling), but it must be something like this.

Note 2: It isn't enough to just call CWnd::OnLButtonDown(). Activating the containing aux dialog seems to be necessary.