Why are my dialog bar buttons are disabled?

I have built an SDI Wizard-generated app CRichEditView (VS 2005 std ed) with a dialog bar class, CDialogBar1, constructed according to

How to initialize child controls in a derived CDialogBar
http://support.microsoft.com/kb/185672

The dialog bar contains two buttons, Add and Remove. Using the Wizard, I added event handlers to the CDialogBar class (OnButtonClickAdd(), etc). But the application shows the two buttons only as disabled.

I don't get it. Can't dialog bar buttons be activated to work within the dialog bar class? :confused:

Did you add UpdateCmdUI handlers?

Quote:

---

Did you add UpdateCmdUI handlers?

---

No. How would that help?

Don't the CmdUI handlers determine if the toolbar buttons should be enabled, checked and so on?

First note that, if you have a simple dialogbar with some buttons, you don't even need to derive from CDialogBar.
To make the dialog bar buttons enabled, just handle the corresponding comand messages in its parent window (usually, the main frame).

Microsoft offers these comments:
http://msdn.microsoft.com/en-us/libr...47(VS.60).aspx

Quote:

---

Dialog Bar Topics
A dialog bar is a toolbar — a kind of control bar that can contain any kind of control. Because it has the characteristics of a modeless dialog box, a object provides a more powerful toolbar.
...
Dialog bars are extensions to a main window and any dialog-bar control-notification messages, such as BN_CLICKED or EN_CHANGE, will be sent to the parent of the dialog bar — the main window.

---

That seems to go along with ovidiucucu 's comments.

By routing the dialogbar buttons message handlers via the mainframe, the dialogbar buttons are enabled. But the only way I am able to carry out the button commands from the mainframe (which, BTW, are intended to affect other controls in the dialogbar itself) is to use a CDialogBar1 public function accessed from the mainframe. This works, but is somewhat cumbersome.

At some point, I would like to disable the dialogbar buttons programatically, but have not been able to figure out how to do this. The obvious strategem, using a CDialogBar1 public method accessed from the mainframe has no effect. Nor does this:

Code:

---

        CButton * pButton = (CButton*)m_wndDlgBar1.GetDlgItem(IDC_BUTTON_ADD);
        pButton->EnableWindow(FALSE);

---

Clearly, I have alot to learn about dialog bars. :)

A good place to learn is look at some of the many samples out there.

Search google for "CDialogBar enable button sample"

I have attached here a simple SDI application which programatically enables/disables a button control from a dialogbar.

// no needed to derive from CDialogBar and use CmdUI handler as Arjay already suggested.

ovidiucucu,

Thank you for taking the time to post the EnableDlgBar program.

I am ashamed to admit that for years I have been led to believe that it was necessary to derive a class based on CDialogBar in order to initialize the child controls of a dialog bar. I came to this conclusion after reading several articles posted on the subject. You and Arjay are the first to suggest to me that all that added coding is unecessary, at least for my purposes.

It is interesting that the Wizard will not let one add a variable to any of the controls contained in a dialog bar resource that has not had an underlying class defined for that resource. This makes the initialization of the child controls slightly more cumbersome.

Another interesting difference between my old method of adding a class for the dialog bar is that the MainFrame member variable, m_wndDialogBar, no longer functions as a class. While that seems obvious, it becomes a bit of a problem when one tries to disable a dialogbar button using,

Code:

---

                CButton * pButton = (CButton*)m_wndDialogBar.GetDlgItem(IDC_BUTTON_ADD);
                pButton->EnableWindow(FALSE);

---

which no longer works using your method, and one must resort to using the CCmdUI* pCmdUI updating methods (which I now understand what Arjay was saying).

Interestingly, one can initialize all of the necessary dialog bar controls using the following type of CMainFrame initialization:

Code:

---

void CMainFrame::InitializeDialogBar1()
{
        CComboBox * pBox = (CComboBox*) m_wndDialogBar.GetDlgItem(IDC_APPCOMBO);
        pBox->AddString("LogOn.key");
        pBox->AddString("CSurgRisk.key");
        pBox->AddString("MatCalc.key");
        pBox->AddString("StudyGroup.key");
        pBox->AddString("Noo.key");
        pBox->SetCurSel(4);


        CEdit * pEdit = (CEdit*)m_wndDialogBar.GetDlgItem(IDC_EDIT1);
        CString cs;
        cs.Format("9C 50 BE 18 5F 7C 11 27\r\nDE 9A AA 24 1E 1F E6 0D\r\n4B BF E3 11 89 33 8F 0E\r\n29 4E 29 26 E9 EF 38 2B");

        pEdit->SetWindowTextA(cs);
}

---

In short, you have brought me to a new level of programming and I thank you. :)

Mike, what is the point of the following code?

Code:

---

cs.Format("9C 50 BE 18 5F 7C 11 27\r\nDE 9A AA 24 1E 1F E6 0D\r\n4B BF E3 11 89 33 8F 0E\r\n29 4E 29 26 E9 EF 38 2B");

---

Arjay,

I just wanted to show that one could initialize a CEdit control and a CComboBox control from the CMainFrame, and that it is not really necessary to build a whole class derived from CDialogBar. The main reason usually given for deriving a separate class is to utilize an OnInitDialog() method to initialize the child controls. Apparently, that is really unecessary.

The code example I provide is simply copied from some test coding I was doing to simulate an application I am building. The numeric string represents a 256-bit AES key. I was just to lazy to change it.

Deriving from a class derived from CControlBar (CDialogBar, CToolBar, and so on) is wonderful for someone trying to do something very special/unusual or for those sleeping with GoF's Little Red Book under the pillow :D

The Class(Good)Wizard has his own limitations. I hope you observed one little "trick" in my example: the button from dialogbar has the same resource ID as a menu item.
Two good reasons for doing that:

1. can be easily maped command and update command UI handlers with the wizard help;
2. an user expects to see the commands form a toolbar or dialogbar in the menu as well.

I see. Thanks, Mike.