Toolkit Pro - Toolbars & DockWindow position problem

Toolbars & DockWindow position problem

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=67
Printed Date: 18 June 2025 at 11:19am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Toolbars & DockWindow position problem

Posted By: pcvuser
Subject: Toolbars & DockWindow position problem
Date Posted: 16 June 2003 at 1:44am

Hi All,

In my application I use a few toolbars (CXTToolBar) and a few dockable windows (CXTDockWin).

I've seen a problem that sometimes the toolbars and windows jump back to their original position (i.e. without the user dragging them, and ignoring registry settings). This happens sometimes when the application is open for a long time, and sometimes when upgrading a version of the application.

I save the users position in the registry, like the examples given. I couldn't replicate this problem on XT examples, so I assume it's my bug, but I need help pinpointing what I did wrong.

Has anyone seen this wierd behavior?

Thanks,

Yair

Replies:

Posted By: kstowell
Date Posted: 02 November 2003 at 1:37pm

Hi Yair,

This is a known problem with the standard toolkit. We are working on correcting this problem over the next couple of releases.

Regards,
Codejock Support

Posted By: Cezariusz
Date Posted: 12 November 2003 at 4:28am

I have the same problem and it's very annoying both for me and my users. I have reported it several times for each version of XT standard since 1.9.0.

I've tried to find a workaround, but it's quite difficult because the problem occures on random ocasions. Usually when the application is in the background for the long time, after using Win+M or Win+D to minimize all windows, after screen saver, after hibernating and so on. But I haven't found a way to reproduce the problem on demand in order to debug it.

One method to reproduce the problem was to quickly minimize and restore application many times, but for that case I have a workaround - override CMainFrame::OnSize and add following code:

if (nType != SIZE_MINIMIZED && cx > 200 && cy > 200)
{
CXTMDIFrameWnd::OnSize(nType, cx, cy);
}

Unfortunately it doesn't solve the problem, because unwanted rearanging still happens on other ocasions.

-------------
mailto:cezariusz.marek@comarch.pl - Cezariusz Marek
http://www.comarch.com/ - http://www.comarch.com/

Posted By: Cezariusz
Date Posted: 28 November 2003 at 12:20pm

Users are getting more and more nervous about this bug. Any chance for a quick fix?

-------------
mailto:cezariusz.marek@comarch.pl - Cezariusz Marek
http://www.comarch.com/ - http://www.comarch.com/

Posted By: Cezariusz
Date Posted: 07 January 2004 at 10:33am

One of users has found a way to reproduce the error:
Run "GUI Visual Studio 7 Demo", arrange toolbars and docking windows in non standard way (for example toolbars in one row, docks in one column). Minimize the application, change the size of the taskbar (make sure it's not auto-hide), restore the application. You will see the layout completely messed up.
Hope it will help the support to find a solution.

-------------
mailto:cezariusz.marek@comarch.pl - Cezariusz Marek
http://www.comarch.com/ - http://www.comarch.com/

Posted By: pcvuser
Date Posted: 08 January 2004 at 7:20am

(copied from a mail sent to support a few month ago)

We managed to trace the problem to your (XT) source code defect.

it seems every time that the bug occurs, these functions are called:
CmainFrame::RecalcLayout() which calls

CWnd::RepositionBars(), which calls
CControlBar::OnSizeParent(), which calls,
CXTDockBar::CalcFixedLayout(BOOL bStretch, BOOL bHorz) - this is the problematic function that should be fixed.

We bypassed this problem in the meantime (we cought most occurances of the bug, but it still happens rarely), by saving our toolbars positions before the bug occurs (added mesage to save toolbars in XTToolkit is change (XTDockContext.cpp CXTDockContext::Track()) - in case WM_LBUTTONUP:

So we would like you to fix the bug for the next version.

Below see more details on the bug:

We managed to define two different scenarios when the bug occurs (there are others which we don't know how to recreate)

You can use the "GUI_VisualStudio6" sample to recreate the problem:

A. 1. move the toolbars in the application, then minimize the application window.

2. enlarge the toolbars at the bottom of the screen to 2 lines.

3. decrease the height of the toolbars to one line.

4. again, enlarge the toolbars at the bottom of the screen to 2 lines.

5. reopen the application, and see the toolbars/dock windows moved

B. in windows 2000 you should right click onthe desktop and go to screen saver->power and change the settings of monitor standby. This will mix up the windows and toolbars

Yair

Posted By: Kimeli
Date Posted: 27 February 2004 at 4:30am

Administrator wrote:

Hi Yair,

This is a known problem with the standard toolkit. We are working on correcting this problem over the next couple of releases.

Regards,
Codejock Support

Any progress happening? Or quick fix etc?

Posted By: MosheY
Date Posted: 19 September 2004 at 11:21pm

Has anyone managed to find a decent fix for this?

This is very annoying!

-------------
Regards,
Moshe Y.

Posted By: xred
Date Posted: 21 September 2004 at 11:27pm

Go on!

Posted By: kinook
Date Posted: 08 March 2005 at 10:07am

This problem still exists in 9.51 (and probably 9.6/601 as well since I don't see anything in the release notes indicating it has been addressed). Some users are reporting that their customizations of toolbars/menus don't always get saved (the app saves the customizations to the registry).

-------------
Automate software builds with Visual Build Pro

https://kinook.com/VBP/" rel="nofollow - http://www.visualbuild.com

Posted By: rwfearnley
Date Posted: 14 March 2005 at 6:44am

We came across this problem ages ago & I am surprised its not been fixed yet. To be fair I think this is also a problem in standard MFC implementation as well (or was when we came across it).

It happens because the Dock Bar layout recalculation can be called when the window is minimized. As the window width is zero at that time, it causes the function to automatically wrap all the toolbars onto separate lines (which is by design if you set the width of a normal window so the toolbars do not fit). As it stands they do not snap back when the window is restored.

We worked around this by overriding the CXTDockBar::CalcFixedLayout and temporarily overriding the stored window size before calling the base class implementation, like this:

//////////////////////////////////////////////////////////// /////////////////

// CHyDockBar - to override toolbar layout function to stop wrapping

class CHyDockBar : public CXTDockBar

{

public:

virtual CSize CalcFixedLayout(BOOL bStretch, BOOL bHorz);

DECLARE_MESSAGE_MAP()

};

CSize CHyDockBar::CalcFixedLayout(BOOL bStretch, BOOL bHorz)

{

// Defeat toolbar 'wrapping' by temporarily pretending that the client area is big

CRect rectLayoutTemp = m_rectLayout;

m_rectLayout.SetRect(0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN));

CSize size = CXTDockBar::CalcFixedLayout(bStretch, bHorz);

m_rectLayout = rectLayoutTemp;

return size;

}

Unfortunately you cannot specify the DockBar class the standard XT Toolkit / MFC functions create, so you have do this yourself:

// NB Overrides standard MFC function to allow creation of derived CDockBar class

// in order to defeat 'toolbar wrapping' effect

void CMainFrame::EnableDocking(DWORD dwDockStyle)

{

// must be CBRS_ALIGN_XXX or CBRS_FLOAT_MULTI only

ASSERT((dwDockStyle & ~(CBRS_ALIGN_ANY|CBRS_FLOAT_MULTI)) == 0);

m_pFloatingFrameClass = RUNTIME_CLASS(CMiniDockFrameWnd);

for (int i = 0; i < 4; i++)

{

if (dwDockBarMap[1] & dwDockStyle & CBRS_ALIGN_ANY)

{

CXTDockBar *pDock = (CXTDockBar *)GetControlBar(dwDockBarMap[0]);
if (pDock == NULL)

{

pDock = new CHyDockBar;

if (!pDock->Create(this,

WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_CHILD|WS_VISIBLE |

dwDockBarMap[1], dwDockBarMap[0]))

{

AfxThrowResourceException();

}

}

}

}

}

The downside is it means the toolbars never automatically wrap when the window is resized, but frankly I prefer this anyway.

Hope that helps

Posted By: karthi_sl
Date Posted: 07 March 2013 at 7:23am

Hi Support,

I am also facing the same problem in CDockBar repositioning problem. we are using older version (2002 release) of Xtreme Toolkit.

Is this problem fixed in Latest release ?

If this is fixed, it will be helpful if you provide the nature of bug fix.

Thanks
Karthi