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 CExtTabMdiWnd Collapse All
Subject Author Date
Offer Har Jul 7, 2008 - 6:44 AM

When switching views from the CExtTabMdiWnd, the OnSetFocus is not called in the views.


Please fix.

Offer Har Jul 8, 2008 - 3:27 PM

I did some more tests in my application, and this is what I found:


1) My application has a view which is created in InitInstance, and is maximized


2) The focus message is lost as long as I do not click anywhere in the view. the minute the view gets the focus once, all the conscutive focus messages are received.


Of-course if I switch views not from the CExtTabMdiWnd I alays get the focus message, so somehow the CExtTabMdiWnd eats these messages...  

Technical Support Jul 8, 2008 - 12:34 PM

We used the TabPages sample for testing where we added the following two message handlers to the CChildView class:

void CChildView::OnSetFocus(CWnd* pOldWnd) 
{
      CWnd::OnSetFocus( pOldWnd );
      TRACE1( "CChildView::OnSetFocus() for %p\r\n", this );
}

void CChildView::OnKillFocus(CWnd* pNewWnd) 
{
      CWnd::OnKillFocus( pNewWnd );
      TRACE1( "CChildView::OnKillFocus() for %p\r\n", this );
}
The handling of both messages was correct. Please notice the MDI child frame window receives the focus first. This happens when MDI child frame window becomes activated. It handles focus gaining and sets focus to its child view window. The view window can be any type of window but it must have the AFX_IDW_PANE_FIRST dialog control identifier which allows the MDI child frame window to determine which of its child windows is the view window. The view window in your project can be un-focused only in the following cases:

1) Focus changing is handled in your MDI child frame window in some special way and, as result, focus is not forwarded to view.

2) Focus changing is handled in the view’s WindowProc() method without invocation of the parent class method.

3) Focus changing is filtered in some PreTranslateMessage() method.

4) Focus changing is filtered in some thread hook procedure.

We are sure all the cases are not related to Prof-UIS source code.

Offer Har Jul 8, 2008 - 3:29 PM

I did some more tests in my application, and this is what I found:


1) My application has a view which is created in InitInstance, and is maximized


2) The focus message is lost as long as I do not click anywhere in the view. the minute the view gets the focus once, all the conscutive focus messages are received.


Of-course if I switch views not from the CExtTabMdiWnd I alays get the focus message, so somehow the CExtTabMdiWnd eats these messages... 

Technical Support Jul 10, 2008 - 1:44 PM

We need your help in reproducing this problem with one of Prof-UIS sample applications or any other test project:

1) Which type of view class should be used? Form view? Edit View? Simple CView? Any other?

2) Do you use any complex routes in message pre-translation?

Could you try to trace the WM_SETFOCUS messages sent to your view window using TRACE***(***) in the PreTranslateMessage() virtual method of your view class? We need to know whether WM_SETFOCUS is not passed through message pre-translation routes?