Err.. Have you actually read the MSDN docs? Get it, it's worth it, or go on the net to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/html/_mfcnotes_tn031.asp Anyway, you won't be mixing classes. Here's a quote from those documentations: CToolBar::GetToolBarCtrl, a member function new to MFC 4.0, allows you to take advantage of the Windows common control's support for toolbar customization and additional functionality. CToolBar member functions give you most of the functionality of the Windows common controls; however, when you call GetToolBarCtrl, you can give your toolbars even more of the characteristics of Windows 95 toolbars. When you call GetToolBarCtrl, it will return a reference to a CToolBarCtrl object. See CToolBarCtrl for more information about designing toolbars using Windows common controls. For more general information about common controls, seeCommon Controls in the Windows 95 SDK Programmer’s Reference. Hope that helps. Essentially, there's no harm, as CToolBar are made from (or using) the CToolBarCtrl. I suggest you go to the docs... you'll learn a heck lot more. :rose:

You can always get the underlying CToolbarCtrl and call its member functions.

Again, no reply.. and again, I've solved the problem ^^ What I do is I create an array of toolbars in my MainFrame, and turn them on and off and redock them as the need arise. Okay.. thanks.

Hi, I'm creating an app with single document but multiple views. I'm trying to dynamically change the toolbar as different views are activated. At the moment, I overwrite the ActivateView() function of each view to make a call to the following function: BOOL CMainFrame::SetupMainFrameToolbar(UINT ToolbarResourceID, BOOL loadToolbar/* = TRUE */) { // Load the toolbar as necessary if (loadToolbar == TRUE) { if (!m_wndToolBar.LoadToolBar(ToolbarResourceID)) { TRACE0("Failed to create toolbar\n"); return (FALSE); } } int tempID, location; CString stringToDisplay, tempString; // Loop through all of the buttons of the toolbar UINT ButtonCounter = m_wndToolBar.GetCount(); for (int index = 0; index < ButtonCounter; index++) { // Get the command ID of the button tempID = m_wndToolBar.GetItemID (index); // Get the string resource associated with that command ID tempString.LoadString(tempID); // Find the last string in that resource location = tempString.GetLength() - tempString.ReverseFind ('\n') - 1; // Cut it and set as the button's title stringToDisplay = tempString.Right (location); m_wndToolBar.SetButtonText (index, _T((LPCTSTR) stringToDisplay)); } // change the toolbar size to accomodate the text m_wndToolBar.SetSizes (TOOLBAR_BUTTON_SIZE, TOOLBAR_BUTTON_IMAGE_SIZE); if (loadToolbar == TRUE) { // Float and redock this toolbar to recalculate sizes FloatControlBar(&(m_wndToolBar), CPoint(50,50)); DockControlBar (&(m_wndToolBar), AFX_IDW_DOCKBAR_TOP); } // Recalculate the main frame's layout to position the toolbar appropriately. RecalcLayout(); // Invalidate the window containing the toolbar so it gets redrawn m_wndToolBar.InvalidateRect (NULL, TRUE); // done correctly return (TRUE); } As you can see, I was forced to float and redock the toolbar, as AutoSize() doesn't work (it clips my new toolbar to the width of the old toolbar) and RecalcLayout() makes my toolbar buggy (text is only displayed after first a mouse has hovered over the toolbar). Anybody has ever done this before? Like totally replace the main toolbar everytime a new view is activated? Help ^^ :-D

Try: // change the toolbar size to accomodate the text m_wndToolBar.SetSizes (TOOLBAR_BUTTON_SIZE, TOOLBAR_BUTTON_IMAGE_SIZE);

Failing to see the relationship with Visual C++, here. In Indonesia all school have (well, don't know now) religious education. I went to a Roman Catholic school there and they have about 3 hours a week on the religion. This include discussion on what the Church thinks, about history, and when you get a bit mature (like in Senior high) debate on sexuality, work, and how the Church perceives those things. In public schools, which are all exclusively Muslim, they have the same things, but from the Islamic point of view. I had Catholic friends going to these schools (some of these public schools are extremely hard to get into and are very good, among the best in the country).They had a choice to attend these classes or to skip it. One of my friends became a very good ping-pong player from skipping these classes. He had no choice, he lived in a rural area, and this school was the only one in the 100km area. So, yeah.. different country, different rules. Indonesia a very religious country, as all poorer nations are. They are proud of their devotion, and good on Them. I also went to High School in New Zealand. Here's there's no such thing as a religious education per se. They practically assume that you are a Christian of some sort. During school assemblies, they pray in the Christian manner: head bowed, hand clapsed together and read from Bible. No accomodation whatsoever for anything else, really.. but hey.. it's an English-based nation.

This is a forum for ppl wanting solutions for Visual C++. Not to answer something that looks like as if it was copied straight from an assignment sheet. If it was an assignment or test.. shame on you. :mad:

Okay, No replies.. either nobody have any idea, or my post is just plain silly. REgardless, I've been corresponding with Michal Mecinski, the author of a really good article about MSDI applications, which can be found at http://www.codeguru.com/doc_view/msdi.html[^]. This is what he's got to say about my problem: Hello, I've been searching the MSDN for some info and din't find much about multithreaded doc/view applications. The only solution I found was to go trough the MFC source code and experiment with various solutions. The application you described sounds more complicated to me. I guess the whole document and view classes would have to be completely rewritten. But I have a different idea. You may create a worker thread for each view, that draws the line plot on a bitmap in memory. The view would need to send a message to the working thread whenever the data is updated. You can copy the data for each thread or let the threads access the data in the document directly (using a semaphore of course). The working thread should actually have two bitmaps - one being displayed in the view (simple BitBlt) and one being drawn by the worker thread. After the plot is drawn you switch the bitmaps and post a message to the view to redraw itself. I think this is much simpler than using multiple UI threads. I used such solution once in an application that was drawing fractals and it worked perfectly. I hope this might help. Regards, Michal Mecinski Any comments, folks? :cool: Two Rivers!

:rolleyes:I would say, you should override the OnKeyDown() function instead. Within that function, check the nChar parameter, and if it is the keyboard button, do your thing, then exit without calling the base class implementation. Or call the baseclass implementation, but change the value of nChar to somnething else that wouldn't be a problem for you. Get back to us on that, please. Two Rivers!

Hi guys, I need an opinion regarding a problem I have. I'm an university student working for a company in New Zealand, developing an MFC application which communicates, through a serial port, to an external device. The application will then subsequently retrieve data, stores it in a document object, and update all views currently opened. There could be many views of the data, involving various line plots. I've written the first version of this application last year, and we found that the lineplot drawing can be very intensive, the User Interface becomes very slow to respond to user clicks, etc. I've looked at maximising the drawing calculations, but there's simply not much I can do to improve it further. The boss surely enough doesn't like this ^^ He wants some improvement made. At the moment, I'm thinking of creating a UI thread for each separate view. That is, everytime user wnats to open a new, say line plot, a new UI thread will be spawned off and in turn a new frame and view will be created to display the data. The problem comes about because data will be continually updated, so the thread must have access to the actual document object, and the mainframe menu must continually be adjusted to account for the different view. For example, when the view is a line plot, certain toolbars must appear, which can be quite different from when a table is displayed. I've been looking all over the net and MSDN for information, but it seems that there is a great reluctance to tackle the multithreaded SingleDocument-Multiple View approach. Nasty, they say =P. I was wondering if nybody can give me some pointers to creating a multithreaded SD/MV framework. Thank you very muc:cool:h. I would greatly appreciate any help anybody can give me.