Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Bug in CExtDynControlBar::NcButtons_HandleClick Collapse All
Subject Author Date
Offer Har Dec 1, 2006 - 5:11 AM

Dear support,
I have further explored my my with tabbed docked bars that are closed using KillBar.
To recap, the scenario is two docked bars tabbed together, and when the ’X’ is pressed they override their NcButtons_HandleClick and call KillBar on thenselves.

My finding is as follows:
When there are two docked bar, the first to get closed works fine, it is closed, killed and destroyed.
When the second is closed, and i get into CExtDynControlBar::NcButtons_HandleClick i see that tab control is still active, even though in the display there is one bar now, what happens is that the line
pTabbedBar->GetBarAt( nTabSel, true );
Return -1 because there is no real tab control anymore, because of that pActiveInTabbedBar is null, and the docked bar virtual function is not called.

Please re-create according to the steps i sent you yesterday, and fix this problem.

Regards,
Ron.

Offer Har Dec 1, 2006 - 5:19 AM

Dear Support,

I have made some more tests on ’normal’ bars (without calling the KillBar)
I found out that when you dock two bards tabbed together, and then close one of the bars, even though there is only one bar now displayed, you still use the CExtDynTabControlBar, and it behaves OK. I can only guess that the problem is in the ordering of things in the CExtDynTabControlBar when KillBar is called. Please also note that i use g_bCloseOnlyOneBarInTabGroup.

I would really appreciate it if we could close this bug today so that we will be able to have the ability to release a version beginning of next week.

Best Regards,
Ron.

Offer Har Dec 1, 2006 - 5:28 AM

From further debugging, I can assume that the problem is that m_nSelIndex of the CExtTabWnd class is not updated correctly when the first bar was destroyed.

Offer Har Dec 1, 2006 - 6:08 AM

After exploring more, i see that the bug is probably in the KillBar function, it calls
pTabbedBar->RemoveSelFromSwitcher();
which leaves the bar control with selected tab -1, which of course does not make sense.

The function KillBar that you directed me towards was not intended to work with tabbed bars i guess, so this is why all this mess occurred.

Offer Har Dec 1, 2006 - 6:37 AM

Dear Support,

I have fixed this bug, and i think you should review my fix, enhance it, and insert it into the next version/patch.

These are the changes:

1) Added the function

LONG GetItemCount() { return m_wndTabSwitcher.ItemGetCount(); } 
To the CExtDynTabControlBar class 2) In the KillBar (which i think should also be a part of the library) I have added after:
pTabbedBar->RemoveSelFromSwitcher();  

these lines:
					
if (-1==pTabbedBar->GetSwitcherSelection() && pTabbedBar->GetItemCount()>0)
{
	pTabbedBar->SetSwitcherSelection(0);
}
 

3) In CExtDynControlBar::NcButtons_HandleClick i have added a variable
bool bForceBaseCall = false; 
4) In CExtDynControlBar::NcButtons_HandleClick after

if( nTabSel >= 0 )
	pActiveInTabbedBar = pTabbedBar->GetBarAt( nTabSel, true );
 

Add

if (pTabbedBar->GetItemCount()<=1)
{
	bForceBaseCall = true;
}
 


5) At the end of CExtDynControlBar::NcButtons_HandleClick
Change
if( ! bRetVal) 
to
if( ! bRetVal || bForceBaseCall)


The reason for 3+4+5 is that when it is the last bar in the tab, we need to call the base class that does the closure of the tab.
If you don’t add it, then you have an empty bar left open...

Best Regards,
Ron