Forum

Thank you for a reply.
I understood the difficulty of that.. but,

> But we are working on this problem now.

now I have strong expectation for the new version by this statement. :-)

You should use your own class derived from CextControlBar ( or CExtToolControlBar, or CExtMenuControlBar ) and override the OnNcAreaButtonsReinitialize() virtual method.

This is the source code of CExtControlBar::OnNcAreaButtonsReinitialize():

void CExtControlBar::OnNcAreaButtonsReinitialize()
{
INT nCountOfNcButtons = NcButtons_GetCount();
if( nCountOfNcButtons > 0 )
return;
NcButtons_Add( new CExtBarNcAreaButtonClose(this) );
#if (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
NcButtons_Add( new CExtBarNcAreaButtonAutoHide(this) );
#endif // (!defined __EXT_MFC_NO_TAB_CONTROLBARS)
NcButtons_Add( new CExtBarNcAreaButtonMenu(this) );
}

If yop remove this line
NcButtons_Add( new CExtBarNcAreaButtonClose(this) );
the "X" button will disappear.

When the control bar window is in the floating state, it is inside a miniframe window which is created and destroyed automatically by Prof-UIS. The "X" on this frame just hides the window.

All the non-client area buttons are instances of the classes which are derived from CExtBarNcAreaButton. You can write your own buttons and initialize them in OnNcAreaButtonsReinitialize().

Please feel free to contact us if you have any problems.

You can fake the icons in the title-bar by implementing your own non-client buttons. Each control bar may have several non-client area buttons (like "X" button of a floating bar). The buttons may be aligned to the left or to the right. They also may paint their own areas. In the MDI sample you can see the "Task-Panel" bar with 2 buttons ("<-" and "->") which are located at the right part of the caption. They are clickable. You should write your own no clickable button, which will paint an icon in its area.
All the buttons are instances of the classes derived from CExtBarNcAreaButton. Your button should be similar to the "<-" or "->" button in the MDI sample but the OnNcAreaDraw() method should paint an icon and OnNcAreaClicked() should do nothing. This button should return a false value in the OnQueryVisibility() method if the control bar is not in the floating state.
To insert your button into the caption of the control bar you need your own class derived from CExtControlBar (or CExtToolControlBar, or CExtMenuControlBar). Your control bar should override the OnNcAreaButtonsReinitialize() virtual method:

void CMyControlBar::OnNcAreaButtonsReinitialize()
{
CExtControlBar::OnNcAreaButtonsReinitialize()
INT nCountOfNcButtons = NcButtons_GetCount();
if( nCountOfNcButtons > 0 )
return;
NcButtons_Add( new CMyIconButton(this) );
}

As we mentioned before, CMyIconButton should be derived from CExtBarNcAreaButton.
Please find the CBarNcTaskAreaBtn class in the MainFrm.h file of the MDI sample and use it as a guide of writing custom non-client buttons.

Please note the vertical height of a floating mini-frame window is usually less than 16 pixels. You may need to paint icons with the height a little bit less than 16. These icons may be 16x16 or 32x32, but any meaningful image should be approximately 12x12. Otherwise your icon may not fit the caption height.

Please contact us if you have any difficulties.

Dear Rajneesh,

You cannot use MFC-extension DLLs (like Prof-UIS) in other DLLs. The DLLs in question should only be used in EXE programs which, in turn, should also be based on MFC.

The solution we can suggest you is to include some of the Prof-UIS source files directly into your ATL project (e.g. ExtTabWnd.*, ExtPaintManager.*). But, in this case, you have to modify those files, i.e. to remove dependency of other library sources.

If you encounter any problems, we can make a test ATL project with the modified version of the tab window inside. BUT PLEASE NOTE: THIS PROJECT WILL NOT USE PROF-UIS DLL.

Dear Rajneesh,

The technique you described cannot be used for inserting new menu items.

Instead you should override the CExtPopupMenuWnd::g_nMsgPrepareMenu registered message in the frame window so that you can modify menus. This message is generated each time any popup menu appears on the screen. Please add this line to the frame’s message map:

ON_REGISTERED_MESSAGE(CExtPopupMenuWnd::g_nMsgPrepareMenu,OnExtMenuPrepare)

You also should add this method to your frame window:

LRESULT CMainFrame::OnExtMenuPrepare(WPARAM wParam, LPARAM lParam)

{

lParam;

CExtPopupMenuWnd::MsgPrepareMenuData_t * pData =

reinterpret_cast< CExtPopupMenuWnd::MsgPrepareMenuData_t * >( wParam );

ASSERT( pData != NULL );

CExtPopupMenuWnd * pPopup = pData->m_pPopup;

ASSERT( pPopup != NULL );

// HERE IS YOUR CODE TO MODIFY pPopup (insert or remove anything)

}

My suggestion is to add some commands to the menu in resources which will be replaced with other commands in the CMainFrame::OnExtMenuPrepare() method. If you don’t need to replace these commands, you may simply remove them.

For example, if we have added an ID_MY_REPLACE_CMD command to the File menu, you should use the following code in the CMainFrame::OnExtMenuPrepare() method:

INT nReplacePos = pPopup->ItemFindPosForCmdID(ID_MY_REPLACE_CMD);

if( nReplacePos >= 0 )

{

// USER SHOULD NOT SEE THIS COMMAND

VERIFY( pPopup->ItemRemove(nReplacePos) );

// YOU ALSO MAY INSERT SOME COMMANDS TO THIS POSITION

VERIFY( pPopup->ItemInsert( (UINT)CExtPopupMenuWnd::TYPE_SEPARATOR, nReplacePos) );

VERIFY( pPopup->ItemInsert( ID_SOME_COMMAND, nReplacePos) );

}

Please note, all commands should be registered in the command manager.The DRAWCLI sample carefully uses this technique to handle OLE menus and insert color-popup submenus.

If you encounter any difficulties, please send us your sample application to support@fossware.com so we can give you a solution.

Dear Rajneesh,

You cannot use MFC-extension DLLs (like Prof-UIS) in other DLLs. The DLLs in question should only be used in EXE programs which, in turn, should also be based on MFC.

The solution we can suggest you is to include some of the Prof-UIS source files directly into your ATL project (e.g. ExtTabWnd.*, ExtPaintManager.*). But, in this case, you have to modify those files, i.e. to remove dependency of other library sources.

If you encounter any problems, we can make a test ATL project with the modified version of the tab window inside. BUT PLEASE NOTE: THIS PROJECT WILL NOT USE PROF-UIS DLL.

Dear Rajneesh,

Yes, you are right. Those functions are really called twice. Please take a look at their declarations:

virtual bool OnTabWndClickedItem( LONG nItemIndex, bool bButtonPressed, INT nMouseButton,UINT nMouseEventFlags );
virtual bool OnTabWndSelectionChange( LONG nOldItemIndex, LONG nNewItemIndex, bool bPreSelectionTest );

When calling OnTabWndClickedItem for the first time, bButtonPressed is set to true and, if the function returns false, it will not be called for a second time. When it is called for a second time, bButtonPressed is false. This is similar to the OnLButtonDown/OnLButtonUp behavior.

When calling OnTabWndSelectionChange for the first time, bPreSelectionTest is set to true too. In case the returned value is false, the second call of OnTabWndSelectionChange will not be done. This allows you to disable selection of some items when you need it.

I think you should start performing your lengthy operation when OnTabWndSelectionChange is being called for a second time (with bPreSelectionTest = false). In this case, the long time operation will be started just after the tab item is repainted to a selected state.

Dear Oliver,

Today we will send you all the files you need.

I cannot say that I have a very fast response what is supposed to be a priority support. :-(

But I have my sollution, to add automatich tool bar with hide functionality for all your control bars.

First add this just after CExtControlBar::FrameEnableDocking() in de CMainFrame:
----------------
if( !CExtControlBar::FrameInjectAutoHideAreas(this)){
        ASSERT( FALSE );
        return -1;
    }
----------------

And now in you application viaw add this part of the code or your painting gets wierd.

----------------
BOOL CSDIDOCVIEWView::PreCreateWindow(CREATESTRUCT& cs)
{
    // TODO: Modify the Window class or styles here by modifying
    // the CREATESTRUCT cs
     cs.style |= WS_CLIPCHILDREN | WS_CLIPSIBLINGS;

    return CView::PreCreateWindow(cs);
}

It seems that some paint commands are lost to paint the dialog bars when running on Windows XP.

Also when I have multiple control bars in one control bar (tabs), sometimes I see the painting occur multiple times.

Hello,
I am trying to test the Prof-UIS sample code SDIDOCVIEW because I think the code is good for our new application.
But, some bugs were found at your programs when I tested it in my computer which has dual monitors and uses Windows XP.
The bugs are as follows.
1. The main menu items appeared at the most right side of the primary monitor when the sample progam "sdidocview.exe"
is excuted on the second monitor.
2. "Assert failed" occures when the smaple program is started form any one monitor and move it to the other monitor
and click the title bar of a docked control bar.

The "assert failed" occured at the line 12300 in ExtControlBar.cpp file.
The line has "ASSERT( rcFrameWnd.left <= rcCircle0.left );".

The followings are call stack values when the assert is failed.
CExtControlBar::InternalDraggingState_t::CalcStateDynamic(CPoint {x=1113 y=309}) line 12299 + 30 bytes
CExtControlBar::_DraggingUpdateState(const CPoint & {x=1113 y=309}) line 8470
CExtControlBar::_DraggingStart(const CPoint & {x=1113 y=309}, const CPoint & {x=86 y=7}) line 8251 + 20 bytes
CExtControlBar::OnLButtonDown(unsigned int 1, CPoint {x=1113 y=309}) line 6632 + 24 bytes
CWnd::OnWndMsg(unsigned int 513, unsigned int 1, long -851886, long * 0x0012fb28) line 1964
CWnd::WindowProc(unsigned int 513, unsigned int 1, long -851886) line 1585 + 30 bytes
CControlBar::WindowProc(unsigned int 513, unsigned int 1, long -851886) line 480 + 20 bytes
CExtControlBar::WindowProc(unsigned int 513, unsigned int 1, long -851886) line 5470
AfxCallWndProc(CWnd * 0x00377ee8 {CExtControlBar hWnd=???}, HWND__ * 0x00090404, unsigned int 513, unsigned int 1, long -851886) line 215 + 26 bytes

You have to make a decison whether we use your product or not ASAP.
Please, let me know what is wrong with my sample program ASAP.

Thanks,
Yong Seok Kim


P.S. ;
Yong Jin Shin who is in purchasement part bought your product Prof-UIS but I am the software team manager who is trying to test your program.
So, please reply your answer to my e-mail adress.

Hello,

I do not manage to put CExtToolControlBar into vertical on 2 columns in a MdiFrame !
How can one do that ?

Thanks,

Fred