About to upgrade software that will be suitable to new Visual Studio version - it not so simple.
It is huge old software. I has performed conversion today but can not yet to see the result today. There were errors that conversion raised during it
So my app works using MFC toolbar creation without issue. If I set a flag, I can make it Dock or Float when the program is started using m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);. The code that does it lives in the OnCreate which of course can only be called once. What I'm looking to do is use my property sheet to allow the user to select the mode of the toolbars Docked or Floating which requires a method outside of the OnCreate. So I have two buttons for testing, one to destroy the toolbar (working) and create which "rebuilds" the toolbar....
I start off with the app in the Docked mode, then I test by destroying the toolbar and then rebuilding it. The rebuild is where my issue is. On the rebuild, it is "adding" some blank space equivalent to the two toolbars (Menu and Button) and the toolbars float....I can drag it out of where it was docked.....and the floating bar works.....but it "leaves behind" the a non functional version of the floating toolbar where it was once docked. If I double click the floating bar, it jumps back to its previously docked location.
So I'm trying to figure out what is needed to correct my code that partially does what I want.....and fix the artifacts.
m_wndOutput.AddStringStatusTab(_T("Error: Icon toolbar is already active, action cancelled"));
m_wndOutput.AddStringDebugTab(_T("Debug: MainFrame--Error: Icon toolbar is already active, action cancelled"));
//CMDIChildWndEx::m_bEnableFloatingBars = TRUE;
// Create ToolBar toolbar
if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_ALIGN_TOP
| CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||
TRACE0("Failed to Create Dialog ToolBar\n");
m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY); // ------- The problem starts with this line...
RepositionBars(AFX_IDW_CONTROLBAR_FIRST, AFX_IDW_CONTROLBAR_LAST, 0, reposQuery, rcClientNew);
m_wndOutput.AddStringStatusTab(_T("I'm created 1 times"));
m_wndToolBar.ShowPane(TRUE, FALSE, TRUE); // Show toolbar
//m_wndToolBar.ShowPane(TRUE, FALSE, TRUE); // Show toolbar
In the rebuild, note the comment of where the problem begins.....If I comment out that line.....I can destroy and rebuild the toolbar with no issue, it is once I enable that line of code which creates the "float" of the toolbar action. I thought by destroying the toolbar and rebuilding it with the same options as the OnCreate function with the float line mentioned above would do it.....but I get weird issues with the toolbar.
I found that via the class I was looking at and reading the class methods when we were looking at the rectangle offsets. I read it as it would recalc the rectangles of the toolbar and plant it, clearly I was incorrect as my result are as you mentioned...not working.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
Context: so I typically have one development machine for about 4 years. The one I'm typing on is 5+ years old (dang, I need to replace). So what happens over that period of time is that I collect SDKs. I don't pay attention. But I'm trying to position code I need in a "highly secure environment" - which means its elephanting impossible to get any work done, but the IT guy promises to install what I request.
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
turns out cleaning up after using a linked list isn`t as simple as I thought.
I know this is wrong but it`s the best code I was able to come up with. Any help for setting me on the correct path is appreciated.
Us old-school C programmers tend to forget about the existence of references. Well done, Greg. That's far cleaner than the pointer-to-pointer version the OP presented, but does exactly the same thing.
To the OP:
On the whole though, except as a learning exercise, and some really rare, odd cases, the STL should be the way to go. It's likely to be safer, perhaps faster, and certainly far better tested than your own implementation. The STL should be part of your basic tool kit for C++ programming.
Keep Calm and Carry On
Last Visit: 31-Dec-99 18:00 Last Update: 3-Oct-23 17:58