Print Page | Close Window

Docking a toolbar at specified position

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Command Bars
Forum Description: Topics Related to Codejock Command Bars
URL: http://forum.codejock.com/forum_posts.asp?TID=23979
Printed Date: 02 July 2020 at 3:37pm


Topic: Docking a toolbar at specified position
Posted By: rdhd
Subject: Docking a toolbar at specified position
Date Posted: 01 May 2020 at 4:42pm
We allow a single toolbar docked at the top of our app under the ribbon. We want the out-of-the-box position of the bar to be centered wrt the frame.

I found the toolbar GetToolbarInfo (and Set...) APIs. Even though they are public, they are useless since the returned structure is not public. I'm not sure if will even help if I had access to the structure. I have found when I save the command bars, CJ writes an "xPos" and other data into the registry for the bar.

So I thought perhaps I could "seed" the registry on the first run of the app and get the bar to move over. But, I have found that even if I manually edit the xPos value in the registry, the bar doesn't move. If I move it dynamically by dragging it and save the bar layout, that value changes. But, changing it manually has no effect. I have stepped thru the load bar layout code and see that toolbar info being seeded with it and even a SetWindowPos call being made with the point (and I see the xPos I set in the registry is used in that call). But when the bar displays, it stays where I last put it.

So it seems the reg entry isn't really used. Except that if I delete the entire hive for that bar ("Application-Bar1" for my bar), it goes back to the default pos at the left of the dockbar/app frame. But, just delete the xPos and yPos instead and CJ still places it as the position I moved it to before saving the bar layout.

Anyone have a suggestion of either how to influence the initial position (xPos is what I care about) or just where CJ is really getting the position from?



Replies:
Posted By: dbrookes
Date Posted: 03 May 2020 at 8:43pm
Hi rdhd.

We do a similar thing in our application by providing a default layout which provide a base for a user-specific layout. I think the MRUDockLeftPos key is used to offset the toolbar.

An alternative would be to do it programmatically, which may be better. At least this way you could account for different frame widths and DPI scaling.
    const CXTPClientRect rcClient(this);
    const CXTPWindowRect rcToolBar(pToolBar);
    CRect rcDock{ rcToolBar };
    rcDock.left = rcClient.Width()/2 - rcToolBar.Width()/2;
    rcDock.right = rcClient.Width()/2 + rcToolBar.Width()/2;
    pCommandBars->DockCommandBar(pToolBar, rcDock, pToolBar->GetDockBar());
I guess you would need to find a way to not do this on every startup :)


-------------
Product: ToolkitPro v19.1.0
OS: Windows 10
Language: C++ (VS2019)


Posted By: rdhd
Date Posted: 08 May 2020 at 2:52pm
Hi dbrookes. With all the CJ stuff, I didn't even think about the MFC style docking calls.

CJ uses the ScreenToClient API when docking so I used your code with a bit of modification. I got the client rect of the app and called ClientToScreen on it. I also then added the .left member of the result to the left and right calculations.


Posted By: rdhd
Date Posted: 08 May 2020 at 3:17pm
By the way, since I call SaveCommandBars on exit and LoadCommandbars on launch, I didn't have to do anything special to detect a "first" startup. I simply dock the bar and then call LoadCommandBars. So, if I start clean and set to the middle and move the bar, I can exit and restart and it resets the pos to where I moved it to before the last exit.



Print Page | Close Window