Re: About OnSetFocus - Subnote - Update

Hi,

Here is an update to OnSetFocus.

The following code snippets are what I am using in my custom control.
Its working nicely.

void CSomeControl::OnKillFocus(CWnd* pNewWnd)
{
 CSomeBase:OnKillFocus(pNewWnd);

 CPoint point;
 ::GetCursorPos(&point);

 CWnd::ScreenToClient(&point);

 CRect Rect;
 GetClientRect(Rect);

 if( Rect.PtInRect(point) )
 {
  SetFocus();
 }
}

int CControl::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
    // When Control becomes active, get the focus. Makes sense.
    SetFocus();
    return CWnd::OnMouseActivate(pDesktopWnd, nHitTest, message);
}

This is a temporary soluction if there is only 1 control in a view.
It will work, but using the above code snippets are better and probably =
how MFC controls work.
void CMyView::OnSetFocus()
{
       GetControl()->SetFocus();
}

Regards,

"Nobody" <Nobody@yahoo.com> wrote in message =
news:u6H85RSxHHA.2432@TK2MSFTNGP04.phx.gbl...
Hi Dave,

I knew commenting out
CView::OnMouseActivate(pDesktopWnd, nHitTest, message);
was going to be bad.

So, to remedy that.
int CMyView::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
   CWnd* pWnd = GetFocus(); //Save Current Focus
   int ret = CView::OnMouseActivate(pDesktopWnd, nHitTest, message);
   pWnd->SetFocus(); //Restore it
   return ret;
}

I suppose I could have done it the easy way.
void CMyView::OnSetFocus()
{
       GetControl()->SetFocus();
}
But, at least I know what is going on now anyways.
And, if I have multiple controls in a View, like that of a Dialog, it =
will work just like a Dialog, but without the tab support.

Regards,
"Nobody" <Nobody@yahoo.com> wrote in message =
news:usIT8ROxHHA.4464@TK2MSFTNGP02.phx.gbl...
Hi David,

I get it now.

It really doesn't matter if you do SetFocus() inside a control in =
OnInit().
Somebody else could be doing SomethingElse()->SetFocus() afterwards, =
which takes the focus away.
I ended up removing OnSetFocus() and OnKillFocus() and the SetFocus() in =
OnInit()

I added this to get it to work correctly.
int CControl::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
    // When Control becomes active, get the focus. Makes sense.
    SetFocus();
    return CWnd::OnMouseActivate(pDesktopWnd, nHitTest, message);
}

Think of it this way. When you tab to controls in a dialog, you would =
think the dialog manager
sets the focus to the next tabbed control, which I suppose is does, =
since it was working correctly.
But, what happens when a control is clicked instead of tabbing? It =
didn't work.
So, Tabbing works, but not if the control is clicked. That was the =
reasoning behind adding OnMouseActivate()

I was also having a problem in the View.
As soon as the Control gets the focus, it was immediately taken away.
Thats probably because when the Control becomes active, it makes the =
View active, which in turn takes away the focus.
So, what I did was this
int CMyView::OnMouseActivate(CWnd* pDesktopWnd, UINT nHitTest, UINT =
message)
{
   // return CView::OnMouseActivate(pDesktopWnd, nHitTest, message);
   return TRUE;
}
That is what I was looking for. This is the function that makes a window =
active.
Sure enough. down inside of CView::OnMouseActive() it has
      CWnd::OnMouseActivate()
      HWND hWndFocus ::SetFocus().
*Note that it could be dangerous to just comment out =
CView::OnMouseActivate() I will probably have to move CView stuff to =
here and just remove ::SetFocus.
I am not having any problems as of yet.

So, that is actually how it works!

Also, in a dialog, I was getting that "Bonk" sound.
I actually don't need the WM_KEYDOWN messages and I just use =
PreTranslateMessage instead.
CControl::OnPreTranslateMessage()
{
   If(pMsg->message == WM_KEYDOWN)
   {
      UINT nChar = (UINT)pMsg->wParam;
      UINT nRepCnt = (UINT)pMsg->lParam & 0xFF00;
      UINT nFlags = (UINT)pMsg->lParam >> 16;
      OnKeyDown(nChar, nRepCnt, nFlags);
      return TRUE; //No further processing needed. No "Bonk" sound.
   }
   return CWnd::PreTranslateMessage()
}

More about controls. If interested.

Dialog Initialization is different from Control.Create()
OnCreate() is not called when used in a Dialog.
Which is messing me up somewhat.

It has to do with embedding Custom Controls in a dialog.
A window is automatically created for you.
That way, you don't need to set the Rect Coodinates. It is done =
automatically.
http://www.codeproject.com:80/miscctrl/customcontrol.asp

Second, I am not getting the WM_INITDIALOG messages, so I have to =
intialize the control manually
BOOL CDlgTest::OnInitDialog()
{
    //I shouldn't have to be doing it this way.
    GetControl()->InitControl();
}

Back to the Drawing board, err make that Keyboard.

Thanks,
"Nobody" <Nobody@yahoo.com> wrote in message =
news:%23wsX5NExHHA.312@TK2MSFTNGP04.phx.gbl...
Hi David,

Your probably right. I haven't gotten to that point just yet.
Like I said, I have not tested it in a Dialog.

The odd thing is that if I don't comment out the =
CWnd::OnKillFocus(pNewWnd);
The messages go directly to the View.

The control has the "Focus", (Need a different word) but the WM_KEYDOWN =
messages are going to the View.
I'm not sure what makes a window "Active", or if it even cares.
I think it is just another rect and somewhere in the background, it does =
something like
IsTopLevelWindow() Yes
PointInRect(point) Yes,
Well then, send mouse messages to that Window.

I don't know exactly what is going on just yet.
I can open a dialog, or any other window and whatever window/control =
gains the focus.
and when I come back to my control, it has focus.
(Note that I do not call set focus again. I only call SetFocus once.)
So, that wouldn't be right if it works like your thinking, which sounds =
correct, I might add.

Maybe it is working like OnMouseMove().
If somehow, WM_MOUSEMOVE is disabled, the control would never get the =
mouse messages.
(That could be very well be the case in a static text control, hence the =
SS_NOTIFY ... for keyboard messages )
but, you don't have to call SetFocus() for mouse messages, yet the mouse =
messages still work in other windows,
That could be very well what is going on.
I could just be enabling Keyboard messages to go to my control instead =
of SetCapture() which keeps the messages
from propagating, which is what you and I are thinking.
That is the best I can figure so far.

I'll put the control in a dialog and let you know how things go.

Heck, I am happy I got this far.

P.S.
Something interesting as far as controls go.
Do you know who sends WM_INITDIALOG or WM_INITIALUPDATE.
That is kind of bugging me. CFrameWnd::OnInitialUpdate() might be doing =
it for the View, but I am not sure
who sends the message to the dialog?

P.S.S. Some beer speak. Rambling on...

Thanks,
"David Ching" <dc@remove-this.dcsoft.com> wrote in message =
news:w3hli.37796$YL5.14917@newssvr29.news.prodigy.net...


focus to


there


get


world


like


from