Forum

Hello

IMPORTANT: I am still using V2.54

I have a toolbar created with Prof-UIS. The toolbar contains an edit field. Now the button just left of this edit field has a strange behaviour: If you press the mouse in the right part of the button the button behaves like pressed (= the visual effect of pressing is there) but does not send an event. If you press the mouse in the left part of the button everything is normal.

I have created a screenshot:

http://download.ierax.ch/buttonpressed.jpg

Here you can see that the button and the edit field slightly overlap.

The code to create the toolbar and the button:

// toolbar
if (!m_wndToolBar.Create(_T("ToolbarWndClass"),this,AFX_IDW_TOOLBAR,
WS_CHILD|WS_VISIBLE|WS_CLIPCHILDREN|WS_CLIPSIBLINGS|
CBRS_TOP|CBRS_TOOLTIPS|CBRS_FLYBY|
CBRS_SIZE_DYNAMIC|CBRS_HIDE_INPLACE) ||
!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
{
TRACE0("Failed to create toolbar\n");
return -1; // fail to create
}

// create page selection text box
if (!this->textBoxPageSelection.Create(WS_CHILD|WS_VISIBLE|ES_CENTER|ES_NUMBER,CRect(0,0,100,17),
&this->m_wndToolBar,ID_PAGE_PAGESELECTION))
{
TRACE0("Failed to create page selection text box\n");
return -1; // fail to create
}
this->textBoxPageSelection.SetFont(CFont::FromHandle((HFONT)::GetStockObject(DEFAULT_GUI_FONT)));

// hook up with toolbar
m_wndToolBar.SetButtonCtrl(m_wndToolBar.CommandToIndex(ID_PAGE_PAGESELECTION),&this->textBoxPageSelection);


Thank you in advance

Thomas

You helped me indirectly. The sample application worked and so I compared the behaviour. As it turned out I called SetSeparatedDropDown for the wrong button.

Thank you. Case closed.

The code lines in your message are related for split toolbar buttons which worked OK in any Prof-UIS versions. It would be helpful if you provide us with a modified version of any of our sample application which demonstrates the problem.

Thanks for the information. I debugged as you asked and I came to the following result:

In method CExtBarButton::OnClick there is a statement

CRect rcBtnDropDownArea = RectDropDown();

This rcBtnDropDownArea has a value of 1/23/198/209 (t/b/l/r) .

The button has a value of 1/23/186/209 (t/b/l/r) and so depending on the click position bDropDownHT will be set to true or false which will determine if the message is sent to my handler or not.

I could not understand how RectDropDown is calculated (too complex) nor what it is for. I speculate though that it has something to do with the IMHO incorrectly positioned edit field right next to the button. As I mentioned in my first post I think that the button and the edit field are overlapping slightly (maybe the 12 pixels that make the width of rcBtnDropDownArea???).

Maybe this information is sufficient for you to give me further clues.

Thank you in advance

Thomas

Unfortunately what you described does not allows us to find out what may be wrong. Could you put these buttons into SDI sample application’s toolbar and re-produce the problem. It should not be difficult to debug the mouse click event in a CExtToolControlBar window and find out where and why the click event is canceled. We also suspect there must be something timer based what changes the currently captured window on the desktop or broadcasts the WM_CANCELMODE message what can really abandon currently tracked toolbar buttons or popup menus.