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 » Tooltips on stacked status bars not working Collapse All
Subject Author Date
Thomas Fuchs Mar 29, 2006 - 4:52 AM

Good morning, me again...

I have another problem with tooltips on status bars, even though I am not sure Prof-UIS causes this troubles. I am using two different status bars on top of each other in a MDI document. Here’s the code snippet for creation (CDocFrame is derived from CMDIChildWnd):

CDocFrame::Create(LPCREATESTRUCT lpCreateStruct)
{
if ( CMDIChildWnd::OnCreate(lpCreateStruct) == -1 )
return -1;

// create first TB on top of second TB
if ( !m_wndTBTop.Create(this) || !m_wndTBTop.SetIndicators(....) )
return -1;

// success so far, setup tooltip text:
m_wndTBTop.SetTipText(0, "Pane 0 on top");

// remove gripper for toolbar on top:
m_wndTBTop.SetBarStyle( m_wndTBTop.GetBarStyle() & ~CBRS_GRIPPER );

// create second toolbar below first toolbar:

if ( !m_wndTBBottom.Create(this) || !m_wndTBBottom.SetIndicators(....) )
return -1;

// success, setup tooltip text:
m_wndTBBottom.SetTipText(0, "Pane 0 on bottom");

// done
return 0;
}

Now in this example, the tooltip "Pane 0 on bottom" shows up, but the one for the toolbar on top does not.

Any ideas?

Thanks and best regards,
Thomas

Chris Anderson Apr 19, 2007 - 11:46 AM

Hi,
I have an application written in SDK. For porting using Prof=UI, I have subclassed using CExtNCW<CWnd> (as I cannot use the CFrameWnd due to the complexity of the existing code). Then I have attatched the CExtStatusControlBar with 4 indicators (    ID_SEPARATOR, ID_INDICATOR_CAPS, ID_INDICATOR_NUM, ID_INDICATOR_SCRL). The Window is displayed with Status bar. But it is not reflecting the keyboard status? Any idea on how to enable capturing of keyboard status in the status bar?

Thanks

Technical Support Apr 20, 2007 - 7:11 AM

Actually there should be no much difference in using CFrameWnd and CWnd class. Please simply replace CWnd with CFrameWnd and the problem with status bar should be gone as well as any other potential problems which occur if you are using control bars in the same window. The CFrameWnd class can also be used as a child window of other window and makes it possible to have dockable toolbars inside a control bar.

Technical Support Mar 29, 2006 - 8:02 AM

Your code snippet has a critical error. Both top and bottom status bars were created using the same identifier (AFX_IDW_STATUS_BAR is used as default in both cases). The problem is fixed by using unique bar identifiers.

Thomas Fuchs Mar 31, 2006 - 5:25 AM

Thanks for your reply, but I am afraid this is not the reason. It does not make a difference at all if I use the same, default or even different identifiers. For some reason the tootips show up on the first status bar on top of the other when I comment the line:

// remove gripper for status bar on top:
// m_wndTBTop.SetBarStyle( m_wndTBTop.GetBarStyle() & ˜CBRS_GRIPPER ); // comment this line and tooltips work!

By the way, in my previous post I always spoke of toolbar in my code snippet. That was a booboo, I meant status bar of course. Anyway, the tooltips are working now (even though I don’t know why), however, Prof-UIS 2.53 shows another problem with the gripper, which Prof-UIS 2.30 did not. In order to prevent painting and handling a gripper on the first status bar, I used an overwritten CExtStatusControlBar class, simply named CExtStatusBar:

class CExtStatusBar:: public CExtStatusControlBar
{
virtual bool OnQueryGripperEnabledState() const { return false; }
}

In Prof-UIS 2.30 that worked perfectly well. To recall my code snippet (now everything correctly named as status bar...)


class CDocFrame : public CMDIChildWnd
{
....
CExtStatusBar m_wndSBTop; // overwritten version of CExtStatusControlBar
CEXtStatusControlBar m_wndSBBottom; // standard version
...
}


CDocFrame::Create(LPCREATESTRUCT lpCreateStruct)
{
if ( CMDIChildWnd::OnCreate(lpCreateStruct) == -1 )
return -1;

// create first status bar on top of second status bar
if ( !m_wndSBTop.Create(this) || !m_wndSBTop.SetIndicators(....) )
return -1;

// alternative creation without making a difference for displaying tooltips:
/*------------------
if ( !m_wndSBTop.Create(this, WS_CHILD|WS_VISIBLE|CBRS_BOTTOM, IDW_STATUSBAR_TOP) || !m_wndSBTop.SetIndicators(....) )
return -1;
-------------------*/

// set tooltip text
m_wndSBTop.SetTipText(0, "Pane 0 on top");

// create second status bar below first status bar:
if ( !m_wndSBBottom.Create(this) || !m_wndSBBottom.SetIndicators(....) )
return -1;

// set tooltip text
m_wndSBBottom.SetTipText(0, "Pane 0 on bottom");

return 0;
}

Now in Prof-UIS 2.53 the gripper for the first status bar does not show up (as requested and as it was in version 2.30), however, when I hover over the gripper area at the right side, the mouse turns into the resizing icon (you know what I mean, that little double-arrow) and I am able to resize the window. Which then causes a weird repainting behavior for both status bars, of course. Again, in version 2.30 this worked perfectly well.

Another funny thing I found out in this connection is what happens if I use the standard MFC CStatusBar classes instead of yours. In this case, the bottom status bar has to created first and then the status bar on top:

class CDocFrame : public CMDIChildWnd
{
....
CStatusBar m_wndSBTop; // standard MFC version
CStatusBar m_wndSBBottom;
...
}

CDocFrame::Create(LPCREATESTRUCT lpCreateStruct)
{
if ( CMDIChildWnd::OnCreate(lpCreateStruct) == -1 )
return -1;

// create bottom status bar first, this one shows the gripper:
if ( !m_wndSBBottom.Create(this) || !m_wndSBBottom.SetIndicators(....) )
return -1;

// create second status bar on top of first status bar without a gripper:

// in order to prevent the gripper, we temporarily change the frame style, see CStatusBar::CreateEx(...)
ModifyStyle(WS_THICKFRAME,0);

if ( !m_wndSBTop.Create(this) || !m_wndSBTop.SetIndicators(....) )
return -1;

// turn style on again:
ModifyStyle(0,WS_THICKFRAME);

return 0;
}

This version works perfectly well. No gripper for the status bar on top, no repainting problems, everything just fine.

Any suggestions?

Best regards,
Thomas

Thomas Fuchs Apr 2, 2006 - 4:34 AM

Hello,

After comparing the CExtStatusControlBar class of version 2.30 with version 2.53, I made the following modification in CExtStatusControlBar::OnNcHitTest(...) to fix the gripper issue:

UINT CExtStatusControlBar::OnNcHitTest(CPoint point)
{
ASSERT_VALID(this);

// modification:
if ( OnQueryGripperEnabledState() )
{

// continue with original Prof-UIS 2.53 code:
CRect rcGrip(0,0,0,0);
CWnd* pWndParentStatus = GetParent();
....

} // of if(...)
// end of modification

// continue with original Prof-UIS 2.53 code:

UINT nHT = (UINT)CStatusBar::OnNcHitTest(point);
if ( nHT != HTCLIENT && !OnQueryGripperEnabledState() )
nHT = HTCLIENT;

return nHT;
}

This version works on my stacked status bars. There is no gripper painted for the status bar on top of the second one, the mouse pointer does not change when hovering over the gripper rectangle and the tooltips work as well.

Please confirm that this modification is safe.

Thank you and best regards,
Thomas

Technical Support Apr 2, 2006 - 5:33 AM

Would you send us some test project that demonstrates the issue? This would allow us to catch the whole picture.

Thomas Fuchs Apr 2, 2006 - 6:59 AM

Thanks for your help. I just tried to email you a zipped project file with 680 kbytes to support@prof-uis.com, but it came back stating "Illegal Attachment".
Please provide a proper email address.

Thanks and best regards,
Thomas

Technical Support Apr 2, 2006 - 7:50 AM

We got it and will tell you what’s wrong soon.