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?
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).
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:
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,
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
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:
can be easily maped command and update command UI handlers with the wizard help;
an user expects to see the commands form a toolbar or dialogbar in the menu as well.
Last edited by ovidiucucu; September 28th, 2009 at 02:35 PM.