• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 791
  • Last Modified:

CToolBar derived Toolbar repositioning

The problem is to put floating CToolBars in same position than that was saved at program end.
A GetWindowRect is done for each ToolBar and the rectangle is saved to the Registry. These coords should be screen-coords. When running the program, it reads the saved rectangle, and, to use FloatControlBar, it converts the above rectangle to Client coords with ScreenToClient.
But floating ToolBars reposition at a wrong position, as shown in the attached pictures.
Code is the following:
WRITING: (B is the CToolBar derived object pointer)
RECT rcNormalPosition;
CWinApp* pApp = AfxGetApp();
B->GetWindowText(Nome,49); // name of the ToolBar
pApp->WriteProfileInt(Nome,"Left",  rcNormalPosition.left); // position
pApp->WriteProfileInt(Nome,"Top",   rcNormalPosition.top);
 pApp->WriteProfileInt(Nome,"Right", rcNormalPosition.right);
pApp->WriteProfileInt(Nome,"State", B->IsFloating());
READING AND POSITIONING: (Again B is the CToolBar object pointer)
RECT r; char Nome[50]; BOOL Floating;
CWinApp* pApp = AfxGetApp();
  if (Floating)
     CPoint pp;
     pp.x=r.left; pp.y=r.top;
     FloatControlBar(B,pp,AFX_IDW_DOCKBAR_TOP); // tried any Docking    
Thanks in advance
  • 3
  • 3
1 Solution
FloatControlBar expects screen coordinates, but you are converting them to client coordinates.  See:
As a diagnostic aid, do the code when running as a non-maximized app.  Move the main window down and to the right, and save the toolbar locations.  Check the registry and eyeball the values... the top/left should be much larger than for a maximized app.
One other thought:  MFC Feaure pack supports a feature that automatically saves and restores all toolbars completely automatically, and taking into consideration the many complications involved.  See:
    MFC Feature Pack for VS 2008 and 2010
gpolAuthor Commented:
Dear Dan
I would like you were right... As a matter of fact, I took away the call to ScreenToClient (I uncorrectly read that DockControlBar was working in client coords), and the situation is now that showed in the two attached pictures: the toolbar goes downwards now.  What happens is well illustrated by the following sequence:
1) I go to the registry and put 0 on the top coord.
2) Running program, it correctly displays the Toolbar at 0 of the screen, covering partially the mainframe
3) I exit the program without doing anything. During this exit, the program executes the code for getting WindowRect of the ToolBar and saves it to the registry: top value is now 18 (I always mean decimal values). So, despite the ToolBar is on the top, at 0 y, GetWindowRect return 18 for top rectangle coord...
4) Reentering the program, the toolbar appears at a lower position, of course. Iit seems of the height of the title bar.
So my opinion is that the GetWindowRect of the ToolBar is not returning the "all window rectangle" but only the part with the buttons, or, at least, the part without the title bar. I guess that I have to investigate better the "metrics" of the toolbar..
Let me know whether I am right or not, and, if possible, what to do. I will also investigate this feature pack you suggest.
Thanks for now
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

gpolAuthor Commented:
the images, but what is happening is clear.
gpolAuthor Commented:
Dear Dan
I think to have resolved, because I subtracted the value given by  ::GetSystemMetrics(SM_CXSIZE) to the top and bottom values returned by GetWindowRect, and now it seems to work. Of course I am still open to your comments.
By the way, do you know why GetWindowRect behaves so on ToolBars? Is it (as usual) my fault, or something not very clear in this situation?.
That does make sense, and yours is a good solution.  I'll describe another below.
In the case where a toolbar has been floated, it actually becomes a child of the little floater  window.  When you query the window location, you still get the location the toolbar -- not its floating container window.
What you could do is:  
See if it is floating, and if so, save the screen coordinates of its parent window.  Apparently that is the window that will get positioned at the time of FloatControlBar.  Another possibility would be to call MoveWindow() on tath parent "mini-frame"
To verify all of this, I suggest that you use the program named Spy++  It will be a lot clearer about which window is a child of which other window.  Another way to solve these problems is to breakpoint the code and single-step into the MFC source code.  It usually becomes clear what is happening soon enough.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now