Archived

This topic is now archived and is closed to further replies.

ControlBar? Dialogbar?

This topic is 4956 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. For a while now, I've been trying to get my mind bent around MFC, and I must say I'm doing better than expected, but one thing (well, actually several) stumps me in particular. I have an MDI application to which I wish to add a dockable toolbar. That's easy enough, but I wish to add controls to it. Something like, for instance, the materials toolbar (the one with the colors) in Paint Shop Pro or the layer palette. Or even something like the classwizard/resourceview/fileview pane in Visual C++ 6. (is that, by the way, done in the same way? Or differently?) Anyway, I've been looking into this, and one book suggests editing the toolbar resourcefile by hand, without using VC (a horrible and undoubtedly wrong method), some articles suggest a controlbar (though that does not seem to be a insertable resource?) and others again suggest the DialogBar. I'm putting my confidence in the dialogbar, because it describes exactly what I want: A toolbar, only you can put controls on it as if it were a dialog. Unfortunately, nor in MSDN, nor via Google, can I find any decent way to implement these things. Is the DialogBar the right choice? Why? Why not? Can anyone point me in the right direction? [edited by - The Keymaster on June 4, 2003 8:28:45 AM]

Share this post


Link to post
Share on other sites
In one of the steps of the MFC AppWizard, there is a pair of option buttons labeled "How do you want your toolbars to look?". If you select "Internet Explorer style ReBars", then all the code to create your dialog bars will be there for you, and you simply have to create a dialog template for it, and set up the message handlers.

If you're trying to add them to an existing program, the best I can suggest is that you create a 'scratch' project with that option, and then copy the ReBar code into your existing main frame class.

[edit] And yes, as far as MFC is concerned, I think dialog bars are what you want here.

[edited by - sbennett on June 4, 2003 9:04:46 AM]

Share this post


Link to post
Share on other sites
Hmm, thanks! I''ll have to look into that, then. Since we''re on the subject... Is it possible to make your menu bar dockable as well? I seem to recall this being possible in several apps I''ve seen... Never found a real use for it, but I''m wondering how it''s done.

Share this post


Link to post
Share on other sites
Okay.. So, I tried it out, and it works pretty well.

Except.....


I want a dialogbar on the left of my application, with a large listbox on it. In the resource editor, I resized the dialog window to proper proportions, and placed the necessary controls on it.

Now, I -can- get it running and aligned to the left, but unfortunately, the dialog bar at the top (with the standard open, copy paste buttons on it) has taken on the height of my dialogbar. Since my dialogbar is rather high (about ten lines visible in the list box on it), my normal dialog bar at the top is now extremely high too. This would make sense if I had placed my dialogbar at the top, but it''s aligned to the left.

Is it somehow possible to let MFC know that my DialogBar is completely separate and that the top bar should not resize itself to fit my dialogbar? Or am I attacking this from the wrong angle to start with?

Share this post


Link to post
Share on other sites
Okay, so I tinkered with it some more, and I think I''ve got it working, so far. And without requiring ReBars (although that is still possible).

Here''s what I do: I create a IDD_DIALOGBAR resource, and throw some controls on it. Normally, when creating a dialog resource, you''d go to ClassWizard and create a custom class for that dialog. The MSDN documentation says that you shouldn''t do that for DialogBars, for some reason. I''m not sure what to do instead... I just press Cancel but that means the question keeps popping up every time you open the ClassWizard. Perhaps I should choose an existing class, but I don''t know which one.

Anyway, I then add a member variable for my DialogBar to the class CMainFrame. Since I didn''t create a custom class, I make a member variable of type CDialogBar. I call it m_wndDlgBar.

Then, in CMainFrame::OnCreate(), after the code creating the status bar, I call m_wndDlgBar.Create() and have it point to all the necessary stuff. My IDD_DIALOGBAR resource, a pointer to the window (this), etcetera. I add some calls to DockControlBar, and presto! All set. It doesn''t even make the normal toolbar extremely high, either. And I can dock it to the top, left, right, bottom, anything I like.

So, now I''m left with two questions:

The MSDN Documentation says:

quote:
While it is normal to derive your own dialog classes from CDialog, you do not typically derive your own class for a dialog bar. 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.


So, what do I do when I open ClassWizard and it asks me if I want to derive a new class?

Secondly, CDialogBar::Create is declared as follows:

BOOL Create( CWnd* pParentWnd, UINT nIDTemplate, UINT nStyle, UINT nID );

Now, I call this function as such:

m_wndDlgBar.Create(this, IDD_DIALOGBAR, CBRS_ALIGN_LEFT | CBRS_ALIGN_RIGHT, IDD_DIALOGBAR);

It works perfectly. What I don''t understand is why I have to pass the resource ID twice; once for nIDTemplate, and once for nID. MSDN describes these arguments as follows:

quote:

nID
The control ID of the dialog bar.

nIDTemplate
The resource ID of the CDialogBar object’s dialog-box template.



What''s the difference between those two? What exactly is the control ID? How is it different from the resource ID?


Share this post


Link to post
Share on other sites
Im bringing UP this thread again because im having the same problem described in the last post. Sorry about using your post. To complement my question. Can put use the handle to the messages of the various elements in my cDialogBar in other class. I dont wanna to put them in the MainFrame class. Is it possible. If so..how?

Share this post


Link to post
Share on other sites
Bang up job there mate. That is exactly what I did to create a dialogbar. But I took it one step further and ignored MSDN''s warning and went ahead and associated a class with it. Compiled it and then BANG! Tons of errors. The bloody thing used a CDialog for the base class. So as I usually do I said to MFC I am gonna do what I want to do. I had to go through and change all the CDialog refrences to CDialogBar. THen bang! All the error went away and I had a class associated with my dialogbar. Now I am not sure what I want to do with it...Store data I guess.

As for your second question. Well chum, I dunno, I always just pass two ID''s and it works, so I call it good.

Now onto sir agemaniac''s q. Well there friend, I don''t quite understand your question. You can either create a seperate and specific CDialogBar class as mentioned above. Or you can just grab the CDialogBar itself everytime you want to access data from it.

Usually it goes something like this:

CDialogBar *TempDialogBar;

TempDialogBar = NameofClassyouarein->GetDialogBar(IDD_DIALOGBAR);

//then to access the data you simply go:

TempDialogBar->nameOfVariable;

The only trick is figuring out how to heck to grab the dialogbar pointer from whatever class you are in that you want to get the data from.

Clear as mud right? Righto! Happy coding to you all mates.

Regards
MrScience101

Share this post


Link to post
Share on other sites
Okay so ignore the above post. Just look at this nice tutorial written by a college professor bloke. It''s awesome! As the mighty American''s are so kind'' of sayin''.

http://cegt201.bradley.edu/~don/MFC/LabDocs/LAB05_6.pdf

It''s a pdf document(duh!) But it is well worth the free download of adobe acrobat reader.

Good luck mates! And happy coding!

Regards,
MrScience101

Share this post


Link to post
Share on other sites